From bstrick@plano.net Sat Jul 01 16:39:16 1995
Received: from dns (dns.plano.net [204.215.60.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA31588 for <hfsig@tapr.org>; Sat, 1 Jul 1995 16:39:12 -0500
Received: from nt-35 (aux44.plano.net) by dns (5.x/SMI-SVR4)
	id AA12115; Sat, 1 Jul 1995 16:41:12 -0500
Date: Sat, 1 Jul 1995 16:41:12 -0500
Message-Id: <9507012141.AA12115@dns>
X-Sender: bstrick@plano.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: bstrick@plano.net (Bob Stricklin)
Subject: Your DSP-93
X-Mailer: <Windows Eudora Version 2.0.2>

I did mail your DSP-93 on Friday morning. It was insured so if it does not
show up in a while let me know.

Also I put in a set of new docs including an operation manual. Also left in
the older assembly manual in case it has something that will help you out.
Can not recal if the schematics were included. If not let me know and I will
mail you a set.

Bob Stricklin, N5BRG

From bstrick@plano.net Sun Jul 02 08:26:17 1995
Received: from dns (dns.plano.net [204.215.60.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id IAA04931 for <hfsig@tapr.org>; Sun, 2 Jul 1995 08:26:11 -0500
Received: from nt-35 (aux31.plano.net) by dns (5.x/SMI-SVR4)
	id AA00123; Sun, 2 Jul 1995 08:28:13 -0500
Date: Sun, 2 Jul 1995 08:28:13 -0500
Message-Id: <9507021328.AA00123@dns>
X-Sender: bstrick@plano.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: bstrick@plano.net (Bob Stricklin)
Subject: Re: [HFSIG:440] Your DSP-93
X-Mailer: <Windows Eudora Version 2.0.2>


Sorry, I posted this note to the wrong address.


>I did mail your DSP-93 on Friday morning. It was insured so if it does not
>show up in a while let me know.
>
>Also I put in a set of new docs including an operation manual. Also left in
>the older assembly manual in case it has something that will help you out.
>Can not recal if the schematics were included. If not let me know and I will
>mail you a set.
>
>Bob Stricklin, N5BRG
>
>

Bob Stricklin, N5BRG

From gjones@tenet.edu Mon Jul 03 03:48:18 1995
Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id DAA14763; Mon, 3 Jul 1995 03:48:04 -0500
Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.12/8.6.12) id DAA31049; Mon, 3 Jul 1995 03:48:03 -0500
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199507030848.DAA31049@Leslie-Francis.tenet.edu>
Subject: 1995 ARRL DCC (Papers Deadline)
To: aprssig@tapr.org (BBS SIG mailing), bbssig@tapr.org (BBS SIG mailing),
        hfsig@tapr.org (HF SIG mailing), netsig@tapr.org (NETSIG mailing),
        amsat-bb@amsat.org (AMSAT BB Mail Group), tapr-tnc@tapr.org
Date: Mon, 3 Jul 1995 03:48:03 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 3204      

1995 ARRL Digital Communications Conference
September 8-10th, 1995
Arlington, Texas (minutes from DFW airport)


     *************  PAPERS DEADLINE July 21st, 1995  **************


	Anyone interested in digital communications is invited to submit a
paper for publication in the Conference Proceedings.  Presentation at the
Conference is not required for publication.  If you know of someone who is
doing great things with digital communications, be sure to personally tell
them about this!  Papers are due by July 21, 1995, and should be submitted
to Maty Weinberg, ARRL, 225 Main Street, Newington, CT 06111 or via the
Internet to mweinberg@arrl.org.  Please contact Maty for detailed format
requirements.


Full text is available on the Internet:
FTP: ftp.tapr.org    WWW:  hhtp://www.tapr.org/tapr    E-Mail: tapr@tapr.org
----------------------------------------------------------------------------


	The ARRL Digital Communications Conference is an international forum
for radio amateurs in digital communications, networking, and related
technologies to meet, publish their work, and present new ideas and
techniques for discussion.  Presenters and attendees will have the
opportunity to exchange ideas and learn about recent hardware and software
advances, theories, experimental results, and practical applications.  The
Digital Communications Conference is not just for the digital elite, but for
digitally-orientated amateurs of all levels of experience.


	The 1995 Digital Communications Conference will be held on September
8-10th, 1995 in Arlington, Texas.  Arlington is just minutes away from the
Dallas/Ft. Worth International Airport, which is located in the middle of
the country, and airfares have never been cheaper for this
conveniently-located conference.


     In addition to the presentation of papers on Saturday, two workshops
will be held during the conference.  On Friday, Keith Sproul, WU2Z, will
hold a workshop on APRS packet-location software.  Keith is the Chair of the
TAPR APRS Special Interest Group, developer of the Macintosh version of
APRS, and a leader in the area of APRS technology.  This is a unique
opportunity to gain insight into this fast growing new digital aspect of
amateur operations that combines computers, packet radio, and GPS (Global
Positioning Satellites).  On Sunday, Dewayne Hendricks, WD8DZP, will conduct
a workshop focusing on a survey of Personal Communications Systems and their
applications and use in the Amateur Radio Service.  Dewayne is an expert in
the area of commercial wireless systems; his company WarpSpeed Imagineering,
focuses on wireless Internet.  This workshop presents an opportunity to
learn how Personal Communications Technology (handheld and small business
wireless systems) can be used in the amateur service.


	Full information on the conference and hotel information can be
obtained by contacting Tucson Amateur Packet Radio, 8987-309 E. Tanque Verde
Road, Tucson, AZ 85749-9399.  Phone: (817) 383-0000.  Fax: (817) 566-2544.
Internet: TAPR@TAPR.ORG  http://www.tapr.org/tapr


Sincerely,
	Greg Jones, WD5IVD - President, Tucson Amateur Packet Radio
	Dave Wolf, WO5H - President, Texas Packet Radio Society


From JALOCHA@chopin.ifj.edu.pl Tue Jul 04 06:43:27 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id GAA29640 for <hfsig@tapr.org>; Tue, 4 Jul 1995 06:43:20 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id NAA21826 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Tue, 4 Jul 1995 13:42:17 +0200
Date: Tue, 4 Jul 1995 13:42 GMT+1
Subject: Re: [HFSIG:436] Re: HFSIG activities
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <9C6FD357C0222014@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"

>It may be useful to use a Hilbert transform especially if your demodulator
>require I/Q paths, i.e. doing complex FFT's. You do need, however, some good
>low pass filters to go with it. All these computational blocks eats at your
>machine ticks, however. If you can fit it in, that will be excellent. We had
>some discussion about this topic under "HF channel simulator". 

So I am following this path right now... I did a major redesign so now
the receiver stages are:

1. Sampling at 9600 Hz
2. Bandpass filter 400-2900 Hz (1650+/-1250 Hz),
   sin(x)/x and cos(x)/x parts, complex output
   - is this called the Hilbert transform ?
3. Downsampling by 3 => makes the sampling rate and bandwidth of 9600/3=3200 Hz
   (I can reduce the sampling rate down to the bandwidth because I analyze
    a complex signal)
4. Complex numeric oscilator and mixer.
5. Sliding window + complex FFT (64 points)
   32 points between symbols => 3200/32 = 100 symbols/sec.
   FFT bins are 50 Hz wide, intended carrier spacing is 150 Hz.

Such design let me do some savings on the FFT CPU cycles
and storage requirements so the current code is more compact.

The transmitter stages are very much similar (they go backwards)
only the oscilator+mixer part is avoided.
Provision for symbol timing adjustment at the receiver is already there.

The "band plan": 15 data carriers spaced by 150 Hz.
First carrier at 600 Hz, last at 2700 Hz. Each carrier is DQPSK modulated
as 100 baud (2 bits/symbol). Total data rate is 15*100*2=3000 bps.
Or shall I go to 30 carriers at 50 baud spaced by 75 Hz ?

I plan to make the modem send some sort of preamble which would enable
fast tuning and symbol-sync. acquisition. For example send every second
carrier unmodulated for tuning preamble, then modulate the carriers
by inverting the phase every symbol for fast symbol-sync.

The current code (DSPCARD4/EVM56002) contains all the stages I described
and it seems to work ! Yesterday I made the modem send the preambles
I described. My expectation is that the modem could auto-tune within +/- 50Hz
without any loss in performance - what do people think, is that enough ?

>For interest sake, could you perhaps tell us a bit more about the FREQ4
>software - where to obtain it etc. These analytical methods and tools are
>useful to know about.

A good revision of FFT software was given already on this list.
I can only confirm that FREQ4 looks very nice, unfortunately
I don't have an SVGA to run the real nice version :-)
However one there is one thing I miss in the FREQ4: the spectrum
averaging feature. There is a "peak" and "decay" display mode but
that's not really averaging.

Pawel
From forrerj@ucs.orst.edu Tue Jul 04 20:28:26 1995
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id UAA03315 for <hfsig@tapr.org>; Tue, 4 Jul 1995 20:28:18 -0500
Received: from p01.t0.monrotel.com by ucs.orst.edu; (5.65v3.0/1.1.8.2/24Sep94-1201PM)
	id AA13889; Tue, 4 Jul 1995 18:28:08 -0700
Message-Id: <9507050128.AA13889@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 04 Jul 1995 17:39:39 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: Re: [HFSIG:443] Re: HFSIG activities

Pawel,


>So I am following this path right now... I did a major redesign so now
>the receiver stages are:
>
>1. Sampling at 9600 Hz
>2. Bandpass filter 400-2900 Hz (1650+/-1250 Hz),
>   sin(x)/x and cos(x)/x parts, complex output
>   - is this called the Hilbert transform ?

Yes, same filters, just 90 degrees phase shifted. 

>3. Downsampling by 3 => makes the sampling rate and bandwidth of 9600/3=3200 Hz
>   (I can reduce the sampling rate down to the bandwidth because I analyze
>    a complex signal)

Good idea - you are picking up some processing gain doing this.

>4. Complex numeric oscilator and mixer.

I suppose this is to go down to zero IF.

>5. Sliding window + complex FFT (64 points)
>   32 points between symbols => 3200/32 = 100 symbols/sec.
>   FFT bins are 50 Hz wide, intended carrier spacing is 150 Hz.

Sounds quite conservative.
Your demodulator is beginning to sound much like Adrian's one for Piccolo.
This very much along the lines I have seen described for several commercial
designs. You are certainly on the right track! 


>
>Such design let me do some savings on the FFT CPU cycles
>and storage requirements so the current code is more compact.
>

I'm not sure why this is the result. Could you tell use why?


>The transmitter stages are very much similar (they go backwards)
>only the oscilator+mixer part is avoided.
>Provision for symbol timing adjustment at the receiver is already there.
>
>The "band plan": 15 data carriers spaced by 150 Hz.
>First carrier at 600 Hz, last at 2700 Hz. Each carrier is DQPSK modulated
>as 100 baud (2 bits/symbol). Total data rate is 15*100*2=3000 bps.
>Or shall I go to 30 carriers at 50 baud spaced by 75 Hz ?

This is well worth a try - 100 baud is approaching the upper limit of what
is feasible due to multipath. If this does not work out as you like, go for
the the 30 carriers at 50 baud.


>
>I plan to make the modem send some sort of preamble which would enable
>fast tuning and symbol-sync. acquisition. For example send every second
>carrier unmodulated for tuning preamble, then modulate the carriers
>by inverting the phase every symbol for fast symbol-sync.
>

This is an extensive topic - we can talk about it a lot. Your suggestion
sounds like a good one - if you can make it work. For such a synchronization
preamble, some folks use say two tones from your set, choosen as far apart
as possible, and they are sent for a duration of say 5 baud times. One tone
is unmodulated and used for doppler estimation and correction. The other
tone is phase shifted by pi at each baud interval and thus gives you symbol
synch. It is also common that doppler tone is sent with say double the
magnitude (6-7dB) than the symbol sync. tone or any of the other carriers
for that matter. There should be no confusion about it. 

Symbol synch/Doppler estimation may be done several ways - a clever idea is
to use you sliding FFT demodulator with a pair of tones that alternates
on/off at the symbol rate. Then estimate your amount of frequency/timing
error using the following maximum-likelihood estimator for a particular
timing interval:

      Error = (r2-r1)/(2(r1+r2))

Where r1 and r2 are the Fourier magnitudes of the two alternating tones
TIMED AT 1/2 the timing interval. For perfect sych. Error=0, and
Error=+/-0.5 at an offset of 1/2T. The explantion is a little involved to
expand on but is very elegantly presented in:

The design of a low data rate MFSK communication system. By Henry D.
Chadwich and James C. Springett. IEEE Trans. on Communications Tech. VOL:
COM-18, No.6 (December 1970) pp.740-750.   

 
>The current code (DSPCARD4/EVM56002) contains all the stages I described
>and it seems to work ! Yesterday I made the modem send the preambles
>I described. My expectation is that the modem could auto-tune within +/- 50Hz
>without any loss in performance - what do people think, is that enough ?

That is remarkable. Let us know when you are ready with an interim version
for testing!


>A good revision of FFT software was given already on this list.
>I can only confirm that FREQ4 looks very nice, unfortunately
>I don't have an SVGA to run the real nice version :-)

What are you missing? The display card or the monitor? I have a card that
you are welcome to have.


>However one there is one thing I miss in the FREQ4: the spectrum
>averaging feature. There is a "peak" and "decay" display mode but
>that's not really averaging.
>

Keep up the good work. Wish I could find more time to join in experiments -
in a little while I hope thigs will ease up a bit.



73's

--Johan, KC7WW

From JALOCHA@chopin.ifj.edu.pl Wed Jul 05 05:08:07 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id FAA07856 for <hfsig@tapr.org>; Wed, 5 Jul 1995 05:07:54 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id MAA29192 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Wed, 5 Jul 1995 12:07:05 +0200
Date: Wed, 5 Jul 1995 12:07 GMT+1
Subject: Re: [HFSIG:444] Re: HFSIG activities
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <584D5BEC4022A761@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"


>>2. Bandpass filter 400-2900 Hz (1650+/-1250 Hz),
>>   sin(x)/x and cos(x)/x parts, complex output
>>   - is this called the Hilbert transform ?
>
>Yes, same filters, just 90 degrees phase shifted. 

A question here: how do I design a good anti-alias filter ?
good = not too many taps and sufficiant alias band rejection.
For the moment I calculate it with sin(x)/x * sin(x)^2 or another window.
I guess I should get some FIR filters design software.

>>4. Complex numeric oscilator and mixer.
>

>I suppose this is to go down to zero IF.

Not really (if I understand the topic right) - normally the NCO
runs at frequency=0 (thus it doesn't affect the signal).
When I need to tune say up 10 Hz I set the NCO to 10 Hz
and when I want to tune down 10 Hz I set it to -10 Hz.

For zero-IF you set the NCO to the center of your passband (1650 Hz) ?

>>Such design let me do some savings on the FFT CPU cycles
>>and storage requirements so the current code is more compact.
>>
>
>I'm not sure why this is the result. Could you tell use why?

The previous design: for 12 tones I had to do a 128 point _real_ FFT.
I don't have a code for real FFT and I only have one for complex FFT
(the one taken from the Motorola buletin board). Thus I was doing twice
the work and after that half of the data was to be put away.
With the current design I do a 64 point _complex_ FFT for 15 tones
and all the resulting bins contain usefull information.
There are some other savings done as well, for example I only store
the bins I want; before I was storing the whole band for several
samples "just in case" I need it for re-tuning - many arrays got smaller,
only the CODEC's buffer stayed huge :-)

>>The "band plan": 15 data carriers spaced by 150 Hz.
>>First carrier at 600 Hz, last at 2700 Hz. Each carrier is DQPSK modulated
>>as 100 baud (2 bits/symbol). Total data rate is 15*100*2=3000 bps.
>>Or shall I go to 30 carriers at 50 baud spaced by 75 Hz ?
>
>This is well worth a try - 100 baud is approaching the upper limit of what
>is feasible due to multipath. If this does not work out as you like, go for
>the the 30 carriers at 50 baud.

This is not a problem for the code, only the mis-tune tolerance
gets decreased by 2 (+/-25Hz ?) unless you do some clever tricks :-)

>>I plan to make the modem send some sort of preamble which would enable
>>fast tuning and symbol-sync. acquisition. For example send every second
>>carrier unmodulated for tuning preamble, then modulate the carriers
>>by inverting the phase every symbol for fast symbol-sync.
>
>This is an extensive topic - we can talk about it a lot. Your suggestion
>sounds like a good one - if you can make it work. For such a synchronization
>preamble, some folks use say two tones from your set, choosen as far apart
>as possible, and they are sent for a duration of say 5 baud times. One tone
>is unmodulated and used for doppler estimation and correction. The other
>tone is phase shifted by pi at each baud interval and thus gives you symbol
>synch. It is also common that doppler tone is sent with say double the
>magnitude (6-7dB) than the symbol sync. tone or any of the other carriers
>for that matter. There should be no confusion about it. 

I like more the idea of many tones. I want to keep the modem resistant
to CW-type jamming. If I use one tone, and the jamming falls onto it...

By the way I wonder whether I should keep symbol sync. frozen once
acquired in the preamble or shall I still follow it during the data phase ?
If I run my sampling on crystals this seems to be not really needed...
or there are some jonospheric effects which could "magically" shift the timing ?
Same thing about tuning correction...
Anyway, _not_ following the symbol timing would do major code saving:
I don't need to sample at twice the symbol rate.
Following the mis-tune doesn't cost much: you only sum up the phase error
and if you see a constant trend you correct the NCO.

>Symbol synch/Doppler estimation may be done several ways - a clever idea is
>to use you sliding FFT demodulator with a pair of tones that alternates
>on/off at the symbol rate. Then estimate your amount of frequency/timing
>error using the following maximum-likelihood estimator for a particular
>timing interval:
>
>      Error = (r2-r1)/(2(r1+r2))

I don't understand yet, but I will think about it :-)

My plan was to synchronize on the alternating phase preamble...
However it would be just simpler to have one common preamble
to do tune and sync. at same time. The one you suggest may be
a good candidate.

>>A good revision of FFT software was given already on this list.
>>I can only confirm that FREQ4 looks very nice, unfortunately
>>I don't have an SVGA to run the real nice version :-)
>
>What are you missing? The display card or the monitor? I have a card that
>you are welcome to have.

My whole PC needs a major upgrade, but I'm going to get a new one
sooner or later, don't worry :-)

Pawel
From paulr@hagar.udc.neweast.ca Wed Jul 05 07:16:25 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAA08296 for <hfsig@tapr.org>; Wed, 5 Jul 1995 07:15:46 -0500
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA25061; Wed, 5 Jul 95 12:15:13 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA804962719; Wed, 05 Jul 95 09:44:47 nst
Date: Wed, 05 Jul 95 09:44:47 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Message-Id: <9506058049.AA804962719@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:445] Re: HFSIG activities

Pawel, 

>>>The "band plan": 15 data carriers spaced by 150 Hz.
>>First carrier at 600 Hz, last at 2700 Hz. Each carrier is DQPSK modulated 
>>>as 100 baud (2 bits/symbol). Total data rate is 15*100*2=3000 bps.
>>>Or shall I go to 30 carriers at 50 baud spaced by 75 Hz 
>? >
>>This is well worth a try - 100 baud is approaching the upper limit of what 
>>is feasible due to multipath. If this does not work out as you like, go for 
>>the the 30 carriers at 50 baud.
>
>This is not a problem for the code, only the mis-tune tolerance
>gets decreased by 2 (+/-25Hz ?) unless you do some clever tricks :-)

If you use less tones for sync, then you can regain the mis-tune 
tolerance. If the receiver knows which tones to expect, and say 
that you are using 4 of the possible 15 spaced at 200Hz (300Hz?), 
then you get 4* the spacing tolerance: 100Hz (150Hz). If my math 
is reasonable a good balance between jamming resistance and 
mis-tune tolerance can be had by using 1/2, 1/4, or 1/8 or the 
tones during tuning.

If you use symbol shaping (raised cosine) and alternate the phase 
each symbol, a rectifier feeding a 100Hz Narrow 2nd order (3Hz 
wide) BPF, then a DPLL, will give quick lockon. 

>>>I plan to make the modem send some sort of preamble which would enable 
>>>fast tuning and symbol-sync. acquisition. For example send every second
>>>carrier unmodulated for tuning preamble, then modulate the carriers 
>>>by inverting the phase every symbol for fast symbol-sync.
>>
>>This is an extensive topic - we can talk about it a lot. Your suggestion 
>>sounds like a good one - if you can make it work. For such a synchronization 
>>preamble, some folks use say two tones from your set, choosen as far apart 
>>as possible, and they are sent for a duration of say 5 baud times. One tone 
>>is unmodulated and used for doppler estimation and correction. The other 
>>tone is phase shifted by pi at each baud interval and thus gives you symbol 
>>synch. It is also common that doppler tone is sent with say double the 
>>magnitude (6-7dB) than the symbol sync. tone or any of the other carriers 
>>for that matter. There should be no confusion about it. 

>I like more the idea of many tones. I want to keep the modem resistant 
>to CW-type jamming. If I use one tone, and the jamming falls onto 
>it...

>By the way I wonder whether I should keep symbol sync. frozen once
>acquired in the preamble or shall I still follow it during the data phase ? 
>If I run my sampling on crystals this seems to be not really needed...
>or there are some jonospheric effects which could "magically" shift the timing 
>? Same thing about tuning correction...
>Anyway, _not_ following the symbol timing would do major code 
>saving: I don't need to sample at twice the symbol rate.
>Following the mis-tune doesn't cost much: you only sum up the phase error 
>and if you see a constant trend you correct the NCO.

Careful of freezing the symbol sync. Crystals are NOT as reliable as you 
think, especially in places varied by temperature (you in death valley and 
your buddy in the Artic <g>). 100ppm (100 parts per million is a common 
error), so 100symbols/sec at 100/1,000,000 = 10,000 symbols before you are 
missalligned by 1 bit (or 5000symbols if 1 end is 100ppm high and the other 
100ppm low). I suspect the modem design could not tolerate more than 2 to 4 
FFT bins of missallignment on a symbol, so 5000 * 1/64 = 78symbols worst 
case, 10000*4/64 = 625 symbols best case. 
So, unless your packets are short, you should run continuous clock 
allignment. One common method is to use wideband and narrow band allignment. 
i.e. allow wide clock adjustment during sync up (8/64 per symbol), and only a 
small allignment during packet reception (1/64 per symbol, or even fractional 
adjusts of say (1/4)/64 (-4 in a row to high/low before correct by 1 clock 
tick).

Tuning tolerance is probably similiar. I suspect that unless you are in a jet 
doing fast turns towards and away from the source, you will have very minor 
doppler (due to ionosphere layer movements, or during the switch from one 
path to another path in multipath). If your CPU can handle it, set it to 
track at probably between 0.1Hz and 1 Hz/symbol (arbitrary values, sorry no 
test data). 

So if you can course tune on a limited tone preamble: adjust for >50Hz error 
to < 10Hz error (Adjust limited to 1/2 the spacing between tones present). 
Then fine tune during the end of the preamble and during the data (adjust 
limited by 1/2 the tone spacing). This would indeed be a nice system. I 
suspect my company (Ultimateast, 709-576-4747, ask for Dwight Howell or John 
Mackey, say Paul Russell referred you) would definitely consider buying an 
implementation (I'm moving to a new job and won't be here to do it myself).

Paul Russell
paulr@neweast.ca (for this and next week)

From JALOCHA@chopin.ifj.edu.pl Wed Jul 05 08:46:00 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA09187 for <hfsig@tapr.org>; Wed, 5 Jul 1995 08:45:52 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id PAA01755 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Wed, 5 Jul 1995 15:45:00 +0200
Date: Wed, 5 Jul 1995 15:44 GMT+1
Subject: Re: [HFSIG:446] Re: HFSIG activities
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <76B89AC62022A761@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"

>If you use less tones for sync, then you can regain the mis-tune 
>tolerance.

Yes, I had this in mind...

>If the receiver knows which tones to expect, and say 
>that you are using 4 of the possible 15 spaced at 200Hz (300Hz?), 
>then you get 4* the spacing tolerance: 100Hz (150Hz). If my math 
>is reasonable a good balance between jamming resistance and 
>mis-tune tolerance can be had by using 1/2, 1/4, or 1/8 or the 
>tones during tuning.

1/4 is better than 1/2 and 1/8 for one "trivial" reason:
if you want to keep same RMS while transmitting 1/4th of the tones
you should increase the tone's amplitudes by a factor of 2.
For 1/2 or 1/8 this factor becomes a bit more ugly :-)

For the moment I put in 4 "tuning" tones: 750, 1350, 1950, 2550 Hz
(600 Hz spacing). Thus is principle I could have +/-300Hz tuning tolerance.
But... my passband is not that wide. I would need to make more "spare"
bandwidth in the transceiver audio. This is another issue to discuss:
I am trying to fit it 2500 Hz of usefull spectrum. Isn't it too much ?
We could as well use only 2000 Hz with 16 tones (like one military standard
does) and leave 200-300 Hz on both sides for tuning corrections
and equipment imperfections ?

>If you use symbol shaping (raised cosine) and alternate the phase 
>each symbol, a rectifier feeding a 100Hz Narrow 2nd order (3Hz 
>wide) BPF, then a DPLL, will give quick lockon.

You mean avoiding the FFT and putting the time-domain samples straight
into the rectifier. This might not be as good as looking at selected
tones after the FFT (jamming resistance again) but it's a good idea.

>So, unless your packets are short, you should run continuous clock 
>allignment. One common method is to use wideband and narrow band allignment. 
>i.e. allow wide clock adjustment during sync up (8/64 per symbol), and only a 
>small allignment during packet reception (1/64 per symbol, or even fractional 
>adjusts of say (1/4)/64 (-4 in a row to high/low before correct by 1 clock 
>tick).

OK. I will run a slow clock adjustment during the data phase.
I was taking a very optimistic 10E-5 crystal stability for my calculations :-)
but if they can be 10E-4...

>Tuning tolerance is probably similiar. I suspect that unless you are in a jet 
>doing fast turns towards and away from the source, you will have very minor 
>doppler (due to ionosphere layer movements, or during the switch from one 
>path to another path in multipath). If your CPU can handle it, set it to 
>track at probably between 0.1Hz and 1 Hz/symbol (arbitrary values, sorry no 
>test data).

Infact for the Doppler shift I was afraid more of transceiver's
instabilities... but I should do a slow adjustments anyway.
General conclusion: do both adjustments all the time !

>So if you can course tune on a limited tone preamble: adjust for >50Hz error 
>to < 10Hz error (Adjust limited to 1/2 the spacing between tones present). 
>Then fine tune during the end of the preamble and during the data (adjust 
>limited by 1/2 the tone spacing). This would indeed be a nice system.

I had in mind coarse tuning adjustment during the tuning preamble
and when the symbol sync. preamble comes, I could refine the tuning
while doing symbol sync. - this is not much a problem.
I suspect this will be the major problem (at least for me) to make the code
do all these things at the right time :-) Tuning, symbol sync., data coding
I know how to do in principle...

>I suspect my company (Ultimateast, 709-576-4747, ask for Dwight Howell or John 
>Mackey, say Paul Russell referred you) would definitely consider buying an 
>implementation (I'm moving to a new job and won't be here to do it myself).

And what happens when I sell the implementation ? Would it be still
available to amateur radio ? :-)

Pawel
From paulr@hagar.udc.neweast.ca Thu Jul 06 08:36:22 1995
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id IAA23159 for <hfsig@tapr.org>; Thu, 6 Jul 1995 08:36:15 -0500
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35)
	id AA00032; Thu, 6 Jul 95 13:36:11 GMT
Received: from cc:Mail by ccsmtp.udc.neweast.ca
	id AA805053979; Thu, 06 Jul 95 11:06:04 nst
Date: Thu, 06 Jul 95 11:06:04 nst
From: "Paul Russell" <paulr@hagar.udc.neweast.ca>
Message-Id: <9506068050.AA805053979@ccsmtp.udc.neweast.ca>
To: hfsig@tapr.org
Subject: Re: [HFSIG:447] Re: HFSIG activities


>1/4 is better than 1/2 and 1/8 for one "trivial" reason:
>if you want to keep same RMS while transmitting 1/4th of the tones 
>you should increase the tone's amplitudes by a factor of 2.
>For 1/2 or 1/8 this factor becomes a bit more ugly :-)

Note: The individual phase sets for each tone don't have to use 
the same reference in DPSK. 
so Tone 1 could use 10, 100, 190, 280     QDPSK
   tone 2 could use 350, 80, 170, 260
etc. 
An optimization program (weeks of background processing time) can 
be written (did something similar for a 4 channel FSK) that will 
try to optimize a good reference for each tone phase set. You 
have to calculate the worst superposition of the output symbol 
for all possible tone phase combinations, while varying each 
starting tone phase reference by 1 sample in the tone generator. 
When done you can gain upto a factor of 2 on a peak to average 
signal amplitude (4* power). 

As long as each set of phases for each tone is ok (DBPSK @180, DQPSK @90, 8 @ 
45...) the sets can have independent offsets, and there are combinations of 
offsets for a tone set that will minimize the peak for the whole symbol set by a
factor of about 2:1.

>For the moment I put in 4 "tuning" tones: 750, 1350, 1950, 2550 Hz
>(600 Hz spacing). Thus is principle I could have +/-300Hz tuning tolerance. 
>But... my passband is not that wide. I would need to make more "spare" 
>bandwidth in the transceiver audio. This is another issue to discuss:
>I am trying to fit it 2500 Hz of useful spectrum. Isn't it too much ?
>We could as well use only 2000 Hz with 16 tones (like one military standard 
>does) and leave 200-300 Hz on both sides for tuning corrections
>and equipment imperfections ?

I would definitely recommend going to a narrower minimum 
requirement, not all Hams may have radios with nice passbands and 
the more general the design the more potential users. Best radio 
I've seen (300-2750Hz) worst (450-2550), so in my experience if 
you only use about (550-2550) it might be best. Or if a protocol 
can be configured to test and drop/ignore the outside tones in 
some connections (like a Trailblaser telephone modem does). Tones 
dropped figured during link setup or by pre-programming? Maybe 
the initial call done using a subset (1000-2000Hz only) then 
after contact eval exactly how wide is available? I know this is 
costly in development time, but it may pay off later in easier 
use.

>>If you use symbol shaping (raised cosine) and alternate the phase 
>>each symbol, a rectifier feeding a 100Hz Narrow 2nd order (3Hz 
>>wide) BPF, then a DPLL, will give quick lockon.
>
>You mean avoiding the FFT and putting the time-domain samples straight 
>into the rectifier. This might not be as good as looking at selected 
>tones after the FFT (jamming resistance again) but it's a good idea.

Constant tone jamming or slow fading falls out as you are only 
tracking the average AC component of the signal power at the BPF. 
Jamming with a pulsing signal at near the baud rate would still 
be a problem, but random data transmitted over the signal in 
similiar modulation will confuse almost everything except maybe 
spread spectrum.

>And what happens when I sell the implementation ? Would it be still 
>available to amateur radio ? :-)

Depends on how you wrote the contract (so yes). This company puts 
most of the propiatary stuff in the protocols, channel 
evaluation, and interconnection to other systems, instead of the 
modulation anyway. Just a thought, can't say at this point 
whether it would be worth the effort. But if you do have 
something in say 6 months give them a call...


Pawel

From gjones@tenet.edu Sat Jul 08 09:38:37 1995
Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id JAA17950; Sat, 8 Jul 1995 09:38:28 -0500
Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.12/8.6.12) id JAA23566; Sat, 8 Jul 1995 09:38:27 -0500
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199507081438.JAA23566@Leslie-Francis.tenet.edu>
Subject: mail_archive
To: bbssig@tapr.org (BBS SIG mailing), netsig@tapr.org (NETSIG mailing),
        hfsig@tapr.org (HF SIG mailing), aprssig@tapr.org (BBS SIG mailing)
Date: Sat, 8 Jul 1995 09:38:26 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 329       

The mail archives for all the SIGs are now updated nightly.

They can be gotten by ftp in each SIG area under mail_archive

ftp://ftp.tapr.org/tapr/SIG/  

In addition, the mail_archive files have been available from the TAPR
listserv.

There are links to the SIGs in the TAPR web page.  
http://www.tapr.org/tapr

Cheers - Greg
From frode@dxcern.cern.ch Mon Jul 10 09:52:43 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA16217 for <hfsig@tapr.org>; Mon, 10 Jul 1995 09:52:24 -0500
Received: from dxcern.cern.ch by dxmint.cern.ch
	id AA28839; Mon, 10 Jul 1995 16:52:20 +0200
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA04406; Mon, 10 Jul 1995 16:52:19 +0200
Date: Mon, 10 Jul 1995 16:52:19 +0200 (MET DST)
From: Frode Weierud <frode@dxcern.cern.ch>
To: HFSIG TAPR <hfsig@tapr.org>
Subject: ANDVT TACTERM Documentation
Message-Id: <Pine.ULT.3.91.950710154436.14265A-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi all,

To keep the subject on multitone modems hot and as an aid in cracking 
open the outstanding problems on Pawel's multitone design like 
synchronization and error correction coding I have the following minor
contributions to make.

I have been reading up on what the commercial and military users have 
done and are doing in the multitone field and I just uploaded a ZIP 
archive on TAPR's FTP server (ftp.tapr.org) in the HFSIG upload 
directory: /tapr/SIG/hfsig/upload with some information on the protocols 
used in the ANDVT TACTERM AND AN/USQ-83(V) modems.

The archive is called andvt.zip and here is the contents of the andvt.txt 
file:

This archive contains a total of three files. 

	- readme	Which you are reading now
	- andvt.asc	ASCII version of The Variable Speed HF Modem
	- andvt.doc	WORD 5.5 version of The Variable Speed HF Modem

If any of the two files andvt.asc and andvt.doc are distributed in a
different format than the present ZIP archive, please make sure to include
this readme file.

The documentation of The Variable Speed HF Modem (VSM) has been extracted
almost verbatim from David  L. Tate's report "The Variable  Speed HF  Modem,
Modulator  Design". NRL Report 9169,  March 20,  1989; NTIS  Report No.:
AD-A244 891.  The parts extracted concerns mainly the description of the
protocols used by the ANDVT TACTERM AND AN/USQ-83(V) modems, hence the file
names andvt.asc and andvt.doc. 

This writeup on the VSM has been made by Frode Weierud, LA2RL, with the
authorisation of the original author David Tate.  On the question of 
copyright etc. David Tate have instructed me as follows:


Dear Mr. Weierud,

The report titled "The Variable Speed HF Modem Modulator Design" is not
copyrighted and you are free to distribute any portion of it as you wish.
If you include any of it in any published report, I would ask that you
reference it as a professional courtesy.

 - David Tate

Therefore the two documents andvt.asc and andvt.doc are also free of any
copyrights, but I insist that the original author's request for proper
referencing is adhered to also in the case of information taken from my two
documents andvt.asc and andvt.doc.


	Frode Weierud, LA2RL
	E-mail	: frode@dxcern.cern.ch

--------------

I hope some of you might get some good ideas about how to handle the 
symbol and bit synchronization in our multitone modem when seeing how it 
is done in the ANDVT TACTERM modem.

Another issue that surely will come up later is error correction coding.
I have recently re-read a paper that deals with this and which I find is 
well written and gives a lot of useful information on error correction 
codes used with parallel and serial tone modems on HF. The reference is:

	P.G. Farrell and R.M.F Goodman, "Soft-decision error control for 
	h.f. data transmission", IEE Proc., Vol. 127, Part F, No.5,
	Oct. 1980. (NB! This is the English Institute of Electrical
	Engineers)

73's Frode, LA2RL	

	Frode Weierud			Phone	: 41 22 7674794
	CERN, SL			Fax	: 41 22 7679185
	CH-1211 Geneva 23, Switzerland	E-mail	: frode@dxcern.cern.ch

From k5yfw@sacdm10.kelly.af.mil Mon Jul 10 21:16:35 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id VAA30230 for <hfsig@tapr.org>; Mon, 10 Jul 1995 21:16:29 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0sVUng-0002EZC; Mon, 10 Jul 95 21:11 CDT
Message-Id: <m0sVUng-0002EZC@sacdm10.kelly.af.mil>
Date: Mon, 10 Jul 95 21:11:51 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:450] ANDVT TACTERM Documentation
To: hfsig@tapr.org
X-orig-date: Mon, 10 Jul 1995 10:07:11 -0500
X-orig-from: Frode Weierud <frode@dxcern.cern.ch>
X-orig-message-ID: <Pine.ULT.3.91.950710154436.14265A-100000@dxcern.cern.ch>

In Frode's message of 10 Jul 1995 at 1007 CDT, he writes:
> To keep the subject on multitone modems hot and as an aid in cracking
> open the outstanding problems on Pawel's multitone design like
> synchronization and error correction coding I have the following minor
> contributions to make.
>
> I have been reading up on what the commercial and military users have
> done and are doing in the multitone field and I just uploaded a ZIP
> archive on TAPR's FTP server (ftp.tapr.org) in the HFSIG upload
> directory: /tapr/SIG/hfsig/upload with some information on the protocols
> used in the ANDVT TACTERM AND AN/USQ-83(V) modems.

The ANDVT TACTERM is of rather old design and I believe was the first
implementation of the 39 parallel tone modem of MIL-STD-188-110A.  If
my memory serves me correctly, the TACTERM is over 10 years old.

For any who read about this device, on voice operation the modem is
the MIL-STD 39 tone modem with all the FEC, etc features of the
MIL-STD turned on.  On data, the modem uses the MIL-STD 16 tone modem
format which does *not* have FEC.  Both modems run at 2400 BPS on HF.

I used the TACTERM on HF data at 2400 BPS (and voice) before and
during Desert Shield/Storm and it beats the pants off of 110 baud (and
300 baud) ASCII, packet, AMTOR and the like...and that is without FEC.
I can just imagine what the 16 tone modem would do with a little FEC.

This would be a good model to duplicate using DSP and a soundcard as
a first effort in getting high speed data on HF.

Walt
From JALOCHA@chopin.ifj.edu.pl Wed Jul 12 04:59:13 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id EAA20877 for <hfsig@tapr.org>; Wed, 12 Jul 1995 04:59:05 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id LAA25591 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Wed, 12 Jul 1995 11:58:16 +0200
Date: Wed, 12 Jul 1995 11:58 GMT+1
Subject: Re: [HFSIG:451] Re: ANDVT TACTERM Documentation
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <D73B85306022A758@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"

>I used the TACTERM on HF data at 2400 BPS (and voice) before and
>during Desert Shield/Storm and it beats the pants off of 110 baud (and
>300 baud) ASCII, packet, AMTOR and the like...and that is without FEC.

You mean TACTERM beats other protocols in the sense of data rate
or better performance in weak propagation conditions ?

>This would be a good model to duplicate using DSP and a soundcard as
>a first effort in getting high speed data on HF.

I am on a very close track actually, if I change decimation ratio
in my design from 3 to 4 I get exactly the tone spacing and symbol rate
used by TACTERM.

One interresting detail of TACTERM I noticed: the tune-in preamble
uses tones from outside the data band... and I don't see a good
reason for this. Why send two tones where you are not going to send
any data ? I would rather filter out this part of audio.

Progress report on my code - as it is now it does the following:

Tx:
- sends four tuning tones for 32 symbols (0.32 second).
- modulates the tuning tones by alternating the phase for 32 symbols.
  This is for the receiver to get symbol-sync.
- switches to 15 tones and sends 100 "random" symbols.
- sends 16 symbols of jamming data so the receiver's DCD switches off
  quickly.

Rx:
- Listens and waits for the tuning tones.
  When found and present for some minimal time the Rx finds out
  the freq. error and switches to sync. wait mode.
- Waits until the tones become bi-modulated in phase.
  If they don't within some timeout the Rx goes back to "listen for tune" mode.
  If they do, and stay modulated for some minimal time, the Rx finds out
  the symbol timing, freq. error and switched to data mode. This part is
  not yet all done and is right now under developement.
- Next, the Rx should receive the data, and do little freq. and symbol-sync.
  adjustments while monitoring the DCD condition. When DCD drops, the Rx
  switches to "listen for tune".

Pawel
From claude@bauv106.bauv.unibw-muenchen.de Wed Jul 12 06:22:54 1995
Received: from gatesrv.rz.unibw-muenchen.de (gatesrv.RZ.UniBw-Muenchen.de [137.193.10.21]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id GAA21461 for <hfsig@tapr.org>; Wed, 12 Jul 1995 06:22:34 -0500
Received: from bauv106.BauV.UniBw-Muenchen.de by gatesrv.rz.unibw-muenchen.de with SMTP id AA17548
  (5.65c+/IDA-1.4.4 for tapr.org); Wed, 12 Jul 1995 13:22:34 +0200
Received:  (4.1/0.008ycf)
        by bauv106.bauv.unibw-muenchen.de (for hfsig@tapr.org) id AA00417; Wed, 12 Jul 95 13:02:19 +0200
From: claude@bauv106.bauv.unibw-muenchen.de (Claude Frantz)
Message-Id: <9507121102.AA00417@bauv106.bauv.unibw-muenchen.de>
Subject: Re: [HFSIG:451] Re: ANDVT TACTERM Documentation
To: hfsig@tapr.org
Date: Wed, 12 Jul 95 13:02:18 MET DST
In-Reply-To: <m0sVUng-0002EZC@sacdm10.kelly.af.mil>; from "WALT DUBOSE - K5YFW" at Jul 10, 95 9:25 pm
Errors-To: claude@bauv106.bauv.unibw-muenchen.de
X-Mailer: ELM [version 2.3 PL11]

According to WALT DUBOSE - K5YFW:

> I used the TACTERM on HF data at 2400 BPS (and voice) before and
> during Desert Shield/Storm and it beats the pants off of 110 baud (and
> 300 baud) ASCII, packet, AMTOR and the like...and that is without FEC.
> I can just imagine what the 16 tone modem would do with a little FEC.

> This would be a good model to duplicate using DSP and a soundcard as
> a first effort in getting high speed data on HF.

Have you any information about the technology used by this TACTERM
(hardware, software) ?

Claude
From frode@dxcern.cern.ch Wed Jul 12 07:24:48 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAA21879 for <hfsig@tapr.org>; Wed, 12 Jul 1995 07:24:43 -0500
Received: from dxcern.cern.ch by dxmint.cern.ch
	id AA18547; Wed, 12 Jul 1995 14:24:39 +0200
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA19334; Wed, 12 Jul 1995 14:24:39 +0200
Date: Wed, 12 Jul 1995 14:24:38 +0200 (MET DST)
From: Frode Weierud <frode@dxcern.cern.ch>
To: hfsig@tapr.org
Subject: Re: [HFSIG:452] Re: ANDVT TACTERM Documentation
In-Reply-To: <D73B85306022A758@chopin.ifj.edu.pl>
Message-Id: <Pine.ULT.3.91.950712140350.9690B-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 12 Jul 1995 JALOCHA@chopin.ifj.edu.pl wrote:

> 
> I am on a very close track actually, if I change decimation ratio
> in my design from 3 to 4 I get exactly the tone spacing and symbol rate
> used by TACTERM.
> 
> One interresting detail of TACTERM I noticed: the tune-in preamble
> uses tones from outside the data band... and I don't see a good
> reason for this. Why send two tones where you are not going to send
> any data ? I would rather filter out this part of audio.
> 

I wonder if it could be implementation related. The HF radio will have a 
300 - 3000Hz IF bandwith so the four Doppler tones will fit OK in this 
bandwith. The two middle tones used for tuning (Doppler tones) 
correspond to data tone No. 6 and No.12 (1462.5 Hz and 2137.5 Hz). The 
distance between the two tones is 675 Hz, which is the distance between all 
the four Doppler tones. 675 Hz is also the distance between the three 
frame sync tones, which correspond to data tones No. 3, 9 and 15. This 
distance of 675 Hz is 6 times the data tone distance which is 112.5 Hz.

I therefore suppose that they wanted to have a different set of tones for 
Doppler preamble and frame preamble, but that they wanted to keep the 
same bin distance of 675 Hz. The symmetrical selection of these tones 
with respect to the data tones then means two of the Doppler tones will 
fall slightly outside the boundary of the data tone set.

Pawel, congratulation with the tremendous progress on your parallel tone 
modem. I am curious to see what will happen when you modulate a SSB rig 
with this waveform. As Paul, I am somewhat afraid we will run into 
problems with the IF bandwith of most HAM rigs. I just read a review of 
the ICOM IC-736 HF rig yesterday, where they proudly announce very steep 
IF filters with 2.1 kHz bandwith, exactly what we don't want, :-)

I know this is not a real problem, but I am afraid we probably will have 
to reduce the number of tones to be sure to fit nicely within a 2.1 kHz 
IF bandwith.

73's Frode

	Frode Weierud			Phone	: 41 22 7674794
	CERN, SL			Fax	: 41 22 7679185
	CH-1211 Geneva 23, Switzerland	E-mail	: frode@dxcern.cern.ch

From JALOCHA@chopin.ifj.edu.pl Wed Jul 12 08:14:59 1995
Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA22767 for <hfsig@tapr.org>; Wed, 12 Jul 1995 08:14:27 -0500
From: JALOCHA@chopin.ifj.edu.pl
Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cyf-kr.edu.pl (8.6.11/8.6.11) with SMTP id PAA28083 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; Wed, 12 Jul 1995 15:13:24 +0200
Date: Wed, 12 Jul 1995 15:13 GMT+1
Subject: Re: [HFSIG:454] Re: ANDVT TACTERM Documentation
To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>
Message-id: <F2734C1AC022A758@chopin.ifj.edu.pl>
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>"

>I am curious to see what will happen when you modulate a SSB rig 
>with this waveform. As Paul, I am somewhat afraid we will run into 
>problems with the IF bandwith of most HAM rigs. I just read a review of 
>the ICOM IC-736 HF rig yesterday, where they proudly announce very steep 
>IF filters with 2.1 kHz bandwith, exactly what we don't want, :-)

Did they say where are the audio band edges ?
Why don't they make a rig with 1 kHz bandwidth ? :-)
Actually it's easier to make a narrow crystal filter than a wide one.
But maybe the IC-738 filter's width is still switchable ?
I know there are rigs with 1.8 kHz bandwidth... if we want to keep
compatibility with these, we have to squeeze the tones even more.

>I know this is not a real problem, but I am afraid we probably will have 
>to reduce the number of tones to be sure to fit nicely within a 2.1 kHz 
>IF bandwith.

I expect this to be a rather minor operation.
I would rather stay with 16 tones but reduce the spacing to 112.5 Hz
and the baud rate to 75 - are here we came to TACTERM :-)
16 is a nice number for FEC-codes... like Walsh functions.
Later we can try 32 tones with 37.5 baud each.

By the way is there an optimal symbol rate for HF and DQPSK ?
If too high, the multi-paths come into effect,
if too low, the phase incoherency affects the data...
so where is the optimum ?

Pawel
From k5yfw@sacdm10.kelly.af.mil Wed Jul 12 23:54:19 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id XAA05468 for <hfsig@tapr.org>; Wed, 12 Jul 1995 23:54:12 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0sWGDL-0002G1C; Wed, 12 Jul 95 23:49 CDT
Message-Id: <m0sWGDL-0002G1C@sacdm10.kelly.af.mil>
Date: Wed, 12 Jul 95 23:49:30 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:452] Re: ANDVT TACTERM Documentation
To: hfsig@tapr.org
X-orig-date: Wed, 12 Jul 1995 05:01:33 -0500
X-orig-from: JALOCHA@chopin.ifj.edu.pl
X-orig-message-ID: <D73B85306022A758@chopin.ifj.edu.pl>

In Pawel's message of 12 Jul 1995 at 0501 CDT, he writes:
> >I used the TACTERM on HF data at 2400 BPS (and voice) before and
> >during Desert Shield/Storm and it beats the pants off of 110 baud (and
> >300 baud) ASCII, packet, AMTOR and the like...and that is without FEC.
>
> You mean TACTERM beats other protocols in the sense of data rate
> or better performance in weak propagation conditions ?

        We had a 300 baud Bell 102 modem device (terminal) and
        PK-232s and other Military modems for 50/100/110/300 baud...
        running RATT, ASCII, AX.25, AMTOR.

        2400 BPS was faster than the others and had acceptable
        thruput during poor signal conditions.  In poor conditions we
        got near 2400 BPS thruput vs no thruput with the 110/300 baud
        modems/protocols.  AMTOR/SITOR worked as well as the TACTERM
        in poor conditions but the thruput of AMTOR/SITOR was no
        comparison.

        I didn't try the TACTERM an any bit rate less than 2400...
        maybe 1200 once.

>
> >This would be a good model to duplicate using DSP and a soundcard as
> >a first effort in getting high speed data on HF.
>
> I am on a very close track actually, if I change decimation ratio
> in my design from 3 to 4 I get exactly the tone spacing and symbol rate
> used by TACTERM.
>
> One interresting detail of TACTERM I noticed: the tune-in preamble
> uses tones from outside the data band... and I don't see a good
> reason for this. Why send two tones where you are not going to send
> any data ? I would rather filter out this part of audio.

        Good show.  I'm sure that the 10+ years of technology since
        the TACTERM was designed/produced should all for improvements
        in the modem protocol.  I do feel that any new modem protocol
        should include FEC.

        If I remember correctly, 2400 BPS is the thruput rate but the
        modulation bit rate is 3100 BPS on the 39 tone...about 1/3 of
        the data is for the FEC.  What would FEC do to a 16 tone
        modem?


>
> Progress report on my code - as it is now it does the following:
>
> Tx:
> - sends four tuning tones for 32 symbols (0.32 second).
> - modulates the tuning tones by alternating the phase for 32 symbols.
>   This is for the receiver to get symbol-sync.
> - switches to 15 tones and sends 100 "random" symbols.
> - sends 16 symbols of jamming data so the receiver's DCD switches off
>   quickly.
>
> Rx:
> - Listens and waits for the tuning tones.
>   When found and present for some minimal time the Rx finds out
>   the freq. error and switches to sync. wait mode.
> - Waits until the tones become bi-modulated in phase.
>   If they don't within some timeout the Rx goes back to "listen for tune" mode.
>   If they do, and stay modulated for some minimal time, the Rx finds out
>   the symbol timing, freq. error and switched to data mode. This part is
>   not yet all done and is right now under developement.
> - Next, the Rx should receive the data, and do little freq. and symbol-sync.
>   adjustments while monitoring the DCD condition. When DCD drops, the Rx
>   switches to "listen for tune".
>
> Pawel
>


73 All,  Walt
From k5yfw@sacdm10.kelly.af.mil Wed Jul 12 23:56:09 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id XAA05490 for <hfsig@tapr.org>; Wed, 12 Jul 1995 23:56:03 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0sWGFA-0002GlC; Wed, 12 Jul 95 23:51 CDT
Message-Id: <m0sWGFA-0002GlC@sacdm10.kelly.af.mil>
Date: Wed, 12 Jul 95 23:51:24 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:453] Re: ANDVT TACTERM Documentation
To: hfsig@tapr.org
X-orig-date: Wed, 12 Jul 1995 06:33:22 -0500
X-orig-from: claude@bauv106.bauv.unibw-muenchen.de (Claude Frantz)
X-orig-message-ID: <9507121102.AA00417@bauv106.bauv.unibw-muenchen.de>

The 16 & 39 tone modems are described in U.S. MIL-STD-188-110A.  I
loaned out my copy but several individuals on the group have copies.

Walt

In your message of 12 Jul 1995 at 0633 CDT, you write:
> According to WALT DUBOSE - K5YFW:
>
> > I used the TACTERM on HF data at 2400 BPS (and voice) before and
> > during Desert Shield/Storm and it beats the pants off of 110 baud (and
> > 300 baud) ASCII, packet, AMTOR and the like...and that is without FEC.
> > I can just imagine what the 16 tone modem would do with a little FEC.
>
> > This would be a good model to duplicate using DSP and a soundcard as
> > a first effort in getting high speed data on HF.
>
> Have you any information about the technology used by this TACTERM
> (hardware, software) ?
>
> Claude
>
From frode@dxcern.cern.ch Thu Jul 13 02:23:15 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id CAA07978 for <hfsig@tapr.org>; Thu, 13 Jul 1995 02:23:11 -0500
Received: from dxcern.cern.ch by dxmint.cern.ch
	id AA26244; Thu, 13 Jul 1995 09:23:09 +0200
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA01299; Thu, 13 Jul 1995 09:23:07 +0200
Date: Thu, 13 Jul 1995 09:23:07 +0200 (MET DST)
From: Frode Weierud <frode@dxcern.cern.ch>
To: hfsig@tapr.org
Subject: Re: [HFSIG:455] Re: ANDVT TACTERM Documentation
In-Reply-To: <F2734C1AC022A758@chopin.ifj.edu.pl>
Message-Id: <Pine.ULT.3.91.950713085413.29937A-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 12 Jul 1995 JALOCHA@chopin.ifj.edu.pl wrote:

> 
> Did they say where are the audio band edges ?
> Why don't they make a rig with 1 kHz bandwidth ? :-)
> Actually it's easier to make a narrow crystal filter than a wide one.
> But maybe the IC-738 filter's width is still switchable ?

The IF/audio bandwidth measured on a IC-736 transceiver in the ARRL lab 
is as follows at the - 6 dB points:
	USB: 401 - 2102 Hz  (1701 Hz)
	LSB: 431 - 2148 Hz  (1717 Hz)

So as you can see rather narrow. The radio has passband tuning and a 
position for fitting a second smaller filter. Usually a 500 Hz filter is 
fitted in the two IFs (9 MHz and 455 MHz).

On the other hand most of the military radios have an IF/audio bandwidth 
of 300 - 3000 Hz at the -3db points, with a group delay variation of 
+-0.5 ms between 800 - 2800 Hz. I think no HAM tranceiver can match this.
 
> 
>By the way is there an optimal symbol rate for HF and DQPSK ?
> If too high, the multi-paths come into effect,
> if too low, the phase incoherency affects the data...
> so where is the optimum ?

Pawel is always asking difficult questions, :-)
It is clear there is an optimum rate at a given moment and for given 
propagation conditions, the only problem is that the propagation varies 
all the time. I have seen a study made by the Swedish Defence 
establishment that tested FSK modulation rates between 37 Baud and 600 Baud.
They found that you even could run happily at 600 Bauds from time to 
time, specially during day time on a good day time frequency. One thing 
to keep in mind when reading such studies is that the military usually 
work with links between 100 - 1000 km, so there is no real DX involved, :-)

>From what I have read so far I think 75 Baud is a very conservative rate 
which undoubtedly will work under almost all conditions. Personally I 
think the optimal, safe rate is closer to 125 Baud. As far as I have 
understood it should also be safer to run 125 Baud DQPSK than 125 Baud 
FSK, but this might again depend on the design of the FSK demodulator.

I have seen a reference to one modem using 66 tones with 37.5 Baud. I 
can't quite remember what waveform it used, but I think it was DPSK.
Personally I think I would use less tones and a higher symbol rate.

73's Frode


	Frode Weierud			Phone	: 41 22 7674794
	CERN, SL			Fax	: 41 22 7679185
	CH-1211 Geneva 23, Switzerland	E-mail	: frode@dxcern.cern.ch

From SONNTAG@vaxa.acdnj.itt.com Thu Jul 13 09:38:51 1995
Received: from vaxa.acdnj.itt.com (vaxa.acdnj.itt.com [151.190.1.3]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id JAA10865 for <hfsig@tapr.org>; Thu, 13 Jul 1995 09:38:46 -0500
From: SONNTAG@vaxa.acdnj.itt.com
Message-Id: <199507131438.JAA10865@dingus.n5lyt.datarace.com>
Date: 13 Jul 95 10:33:00 EST
Subject: address
To: "hfsig" <hfsig@tapr.org>

For some reason my address has spontaineously changed to an incorrect address. Please
change "Snntag@... to "Sonntag@...". 

				Thanks!

From gjones@tenet.edu Thu Jul 13 10:40:48 1995
Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id KAA11776; Thu, 13 Jul 1995 10:40:42 -0500
Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.12/8.6.12) id KAA01205; Thu, 13 Jul 1995 10:40:37 -0500
From: Greg Jones <gjones@tenet.edu>
Message-Id: <199507131540.KAA01205@Leslie-Francis.tenet.edu>
Subject: Re: [HFSIG:459] address
To: hfsig@tapr.org
Date: Thu, 13 Jul 1995 10:40:36 -0500 (CDT)
Cc: n5lyt@dingus.n5lyt.datarace.com (Lee Ziegenhals)
In-Reply-To: <199507131438.JAA10865@dingus.n5lyt.datarace.com> from "SONNTAG@vaxa.acdnj.itt.com" at Jul 13, 95 09:42:21 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 324       

I am sorry, but on the listserv you are listed as: SONNTAG@VAXA.ACDNJ.ITT.COM

Your problem might be elsewhere.

Cheers - Greg

According to SONNTAG@vaxa.acdnj.itt.com:
> 
> For some reason my address has spontaineously changed to an incorrect address. Please
> change "Snntag@... to "Sonntag@...". 
> 
> 				Thanks!
> 
> 

From chbrain@dircon.co.uk Thu Jul 13 13:13:20 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id NAA14530 for <hfsig@tapr.org>; Thu, 13 Jul 1995 13:13:10 -0500
Received: by felix.dircon.co.uk id AA24625
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 13 Jul 1995 19:12:07 +0100
Message-Id: <199507131812.AA24625@felix.dircon.co.uk>
Received: from ac045.pool.dircon.co.uk(193.128.230.45) by amnesiac via smap (V1.3)
	id sma024601; Thu Jul 13 19:11:37 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Jul 1995 17:21:51 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Hilbert

Here is a question for the group,

 If one implements a Hilbert Transform using a FIR filter and the
Parks Mc Clelland algorithm which sample in the input buffer is the
one that is 90 deg phase different? is it the one in the middle?

Regards Confused!
-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From k5yfw@sacdm10.kelly.af.mil Thu Jul 13 18:23:26 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id SAA19639 for <hfsig@tapr.org>; Thu, 13 Jul 1995 18:23:20 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0sWXWh-0002FEC; Thu, 13 Jul 95 18:18 CDT
Message-Id: <m0sWXWh-0002FEC@sacdm10.kelly.af.mil>
Date: Thu, 13 Jul 95 18:18:39 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:458] Re: ANDVT TACTERM Documentation
To: hfsig@tapr.org
X-orig-date: Thu, 13 Jul 1995 02:30:11 -0500
X-orig-from: Frode Weierud <frode@dxcern.cern.ch>
X-orig-message-ID: <Pine.ULT.3.91.950713085413.29937A-100000@dxcern.cern.ch>

In Frode's message of 13 Jul 1995 at 0230 CDT, he writes:
> On Wed, 12 Jul 1995 JALOCHA@chopin.ifj.edu.pl wrote:
>
> >
> > Did they say where are the audio band edges ?
> > Why don't they make a rig with 1 kHz bandwidth ? :-)
> > Actually it's easier to make a narrow crystal filter than a wide one.
> > But maybe the IC-738 filter's width is still switchable ?
>
> The IF/audio bandwidth measured on a IC-736 transceiver in the ARRL lab
> is as follows at the - 6 dB points:
>       USB: 401 - 2102 Hz  (1701 Hz)
>       LSB: 431 - 2148 Hz  (1717 Hz)
>
> So as you can see rather narrow. The radio has passband tuning and a
> position for fitting a second smaller filter. Usually a 500 Hz filter is
> fitted in the two IFs (9 MHz and 455 MHz).
>
> On the other hand most of the military radios have an IF/audio bandwidth
> of 300 - 3000 Hz at the -3db points, with a group delay variation of
> +-0.5 ms between 800 - 2800 Hz. I think no HAM tranceiver can match this.

        The Harris transceivers used by the U.S. DoD (AN/URC-119) do
        indeed have a 300 - 3000 Hz, 3db bandpass as well as others
        used by DoD agencies.  This is one reason the TACTERM and
        other MIL-STD-188-110A modems work so well with these systems.

        IMHO, we (hams) will have to decide if we want to "build" a
        modem to fit into a 500 -2100 Hz -6db bandpass or replace the
        filters in our HF rigs for ones that will be 300 - 3000 Hz.

        Admittedly those of us interested in high speed HF data
        transmission will initially be a very small minority. However,
        I believe once we can show that robust 2400 BPS data can be
        sent on HF, there will be many clamoring to get this "new"
        ham technology.  At this point, manufacturers may begin
        offering an optional wide SSB filter.

        I would recommend that you (I didn't say we because I'm not
        doing the "work") begin with a modulation scheme that will
        fit into a 500 - 2100 Hz bandpass with the ability to expand
        to a scheme that can use a 300 - 3000 Hz bandpass.

> Pawel is always asking difficult questions, :-)
> It is clear there is an optimum rate at a given moment and for given
> propagation conditions, the only problem is that the propagation varies
> all the time. I have seen a study made by the Swedish Defence
> establishment that tested FSK modulation rates between 37 Baud and 600 Baud.
> They found that you even could run happily at 600 Bauds from time to
> time, specially during day time on a good day time frequency. One thing
> to keep in mind when reading such studies is that the military usually
> work with links between 100 - 1000 km, so there is no real DX involved, :-)

        The above is mostly true...actually 40/45 - 1200/1500 km and
        they try to punch thru as much data as possible in the
        shortest time.  Thus, they will use 300 (even 600) baud AFKS
        when conditions would hardly support 150 baud.

> >From what I have read so far I think 75 Baud is a very conservative rate
> which undoubtedly will work under almost all conditions. Personally I
> think the optimal, safe rate is closer to 125 Baud. As far as I have
> understood it should also be safer to run 125 Baud DQPSK than 125 Baud
> FSK, but this might again depend on the design of the FSK demodulator.

        HAL, in their CLOVER II papers, suggest that 150 baud is the
        maximum baud rate to consider using on HF.  This is also
        suggested by Harris Corp, Rockwell Collins and Magnavox.
        They may all be using data from research done by Stanford
        Research Institute.  Many "old-timers" say the reason RTTY
        and ASCII were never used above 100/110 baud, respectively,
        is that at the end of WWII it was determined that these were
        the maximum baud rates that HF would support.

> I have seen a reference to one modem using 66 tones with 37.5 Baud. I
> can't quite remember what waveform it used, but I think it was DPSK.
>             Personal                            ly      I think I
would use less tones and a higher symbol rate. >
> 73's Frode
>
>
>       Frode Weierud                   Phone   : 41 22 7674794
>       CERN, SL                        Fax     : 41 22 7679185
>       CH-1211 Geneva 23, Switzerland  E-mail  : frode@dxcern.cern.ch
>

73,  Walt@home.2.nite

===========================================================================
Kelly AFB, TX and McClelland AFB, CA were *not* saved.  Another great U.S.
military mistake.  We should have learned from General Custer's mistake.

This is my personal opinion and does in no way represent the view of the
DoD, USAF or any other official U.S. Government Agency.

                           Walter D. DuBose
============================================================================
From forrerj@ucs.orst.edu Thu Jul 13 18:41:46 1995
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id SAA19988 for <hfsig@tapr.org>; Thu, 13 Jul 1995 18:41:31 -0500
Received: from p08.t0.monrotel.com by ucs.orst.edu; (5.65v3.0/1.1.8.2/24Sep94-1201PM)
	id AA04815; Thu, 13 Jul 1995 16:41:20 -0700
Message-Id: <9507132341.AA04815@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Jul 1995 15:53:30 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: Re: [HFSIG:461] Hilbert

Charles,


Good question.


>Here is a question for the group,
>
> If one implements a Hilbert Transform using a FIR filter and the
>Parks Mc Clelland algorithm which sample in the input buffer is the
>one that is 90 deg phase different? is it the one in the middle?
>


Lets see - think of it this way. Consider the Hilbert transform as a black
box where you feed your real-valued time series in. The Hilbert transformer
takes one input and has two outputs, the two outputs are identical except
that they are 90 degrees out of phase, i.e. like sine is the same as a
cosine 90 degrees phase shifted. The output of the Hilbert transformer is
now an analytical signal where one branch could be thought of as the "real"
and the other the "imaginary". This arrangement has some "magical"
properties when it comes to modulation/demodulation but I'll leave that for
the moment. To return to the question: EVERY point of the input buffer is
affected by the transformation. Its kind of similar as doing an FFT and
taking a frequency bin and asking "which data point from the time series
made this bin's content?" The answer is "each and every data point". 


Some other useful tips about the Hilbert transform.
----------------------------------------------------

1)  Be aware of Parks-McClellan FIR code laying around the Internet. Many
version does not compute a valid Hilbert transform - the way you know is to
inspect the coefficients, they should alternate with every other one being
equal zero.

2) If you use a single FIR Hilbert transform for your "Q" branch, make sure
that the other branch i.e. your "I" is delayed by the "same" group delay,
i.e. if your Hilbert transform has 39 taps, you need a delay of 39/2 = 19.5
(use either 19 or 20) taps delay for your "I".

3) One may also do the same thing using regular "comb" FIR filters (every
other coefficient being zero). Then derive two versions from this set of
coefficients, one multiplied by cosine, the other by sine. Now you will have
90 degree difference in the paths, but also have the correct group delay in
each path.

4) If you use the P-McC algorithm for designing the transform, you will find
that it is impossible to attain infinitely narrow transition zones. These
will result in "holes" in the transform - particularly at the origin and
band edge. Most often you may just ignore these effects, but be aware that
you need high enough order filter (look at the number of dB rejection you
get - anything better than say 30-40 dB is usable).   


Above is more or less correct - feel free to jump in and correct me
otherwise. I'm also just learning about the finer points.


73's

--Johan


From bm@lynx.ve3jf.ampr.org Thu Jul 13 21:25:08 1995
Received: from lynx.ve3jf.ampr.org (lynx.ve3jf.ampr.org [44.135.96.100]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id VAA21143 for <hfsig@tapr.org>; Thu, 13 Jul 1995 21:25:01 -0500
Received: by lynx.ve3jf.ampr.org (Linux Smail3.1.28.1 #14)
	id m0sWaQy-0002qeC; Fri, 14 Jul 95 02:24 GMT
Message-Id: <m0sWaQy-0002qeC@lynx.ve3jf.ampr.org>
From: bm@lynx.ve3jf.ampr.org (Barry McLarnon VE3JF)
Subject: Re: [HFSIG:455] Re: ANDVT TACTERM Documentation
To: hfsig@tapr.org
Date: Fri, 14 Jul 1995 02:24:56 +0000 (GMT)
In-Reply-To: <F2734C1AC022A758@chopin.ifj.edu.pl> from "JALOCHA@chopin.ifj.edu.pl" at Jul 12, 95 08:23:13 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1932      

Pawel asks:
> By the way is there an optimal symbol rate for HF and DQPSK ?
> If too high, the multi-paths come into effect,
> if too low, the phase incoherency affects the data...
> so where is the optimum ?

This is an age-old question.  :-)  I have a copy of a paper from 1962
(8th Nat'l Communications Symposium) by one Heinz Fiege-Kollmann,
entitled "The optimum bit length for HF data transmission", in which he
concludes that the optimum symbol length for DPSK lies somewhere between
5 ms and 15 ms.  He says that the optimum is a broad one, but that
performance degrades more quickly as the symbol length is shortened
than when it is increased.  This was based on work done during the
devlopment of the granddaddy of all parallel-tone modems, the Collins
Kineplex, in the mid- to late-50's.  The oldtimers usually used 75 or
100 baud, and they probably knew what they were doing... :-)

Just think of all those racks of equipment that can now be replaced by
one DSP chip...

One common technique in parallel-tone modems that I don't recall seeing
mentioned here (but I probably missed it) is the use of a guard interval
during the first part of the symbol interval.  Energy received during
the guard interval, which hopefully includes most of the multipath, is
excluded from the decision process.  One set of parameters that comes to
mind (probably from Kineplex) is an overall symbol length of 13.33 ms
and a useful symbol length of 9.09 ms, giving 4.24 ms of guard time and
an orthogonal tone spacing of 110 Hz.  Guard intervals are also used for
multipath mitigation in the more recent high-speed VHF/UHF OFDM systems,
such as the Eureka 147 DAB system.  For example, Eureka Mode 1 has a 0.25
ms guard interval, 1 ms useful symbol length, and 1536 tones(!) with 1
kHz spacing.

Barry

-- 
Barry McLarnon  VE3JF/VA3TCP 
Ottawa Amateur Radio Club Packet Working Group
Email: bm@hydra.carleton.ca  or bm@lynx.ve3jf.ampr.org
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Hi Barry,


<<---some lines deleted--->>

>One common technique in parallel-tone modems that I don't recall seeing
>mentioned here (but I probably missed it) is the use of a guard interval
>during the first part of the symbol interval.  Energy received during
>the guard interval, which hopefully includes most of the multipath, is
>excluded from the decision process.  One set of parameters that comes to
>mind (probably from Kineplex) is an overall symbol length of 13.33 ms
>and a useful symbol length of 9.09 ms, giving 4.24 ms of guard time and
>an orthogonal tone spacing of 110 Hz.  Guard intervals are also used for
>multipath mitigation in the more recent high-speed VHF/UHF OFDM systems,
>such as the Eureka 147 DAB system.  For example, Eureka Mode 1 has a 0.25
>ms guard interval, 1 ms useful symbol length, and 1536 tones(!) with 1
>kHz spacing.


Yes, quite right - thanks for reminding us about this issue:

In addition to the multipath performance, there is yet another reason for
the guard bands: 

In J.D. Ralphs' book: Principles and Practise of Multi-frequency Telegraphy, 
page 41, the theory of the guard time is discussed. The gist of the idea is
that most of the spectral spill-over into adjacent bins occurs at bit
transitions and are mostly noticible right right at or near those time
instances. If a "dead" zone or guard interval is used (i.e. the
integrator/FFT excuding that part of the signal), he shows a significant
improvement in demodulator S/N is possible due to using the guard band. 

This same book (page 113) looks at the 16 DPSK parallel-tone modem and
mentions a guard band of 4 ms out of the 13.3ms (75 baud) used for those
modems. There are some further examples of this topic - I'm too lazy to look
for them at the moment.

--Johan Forrer, KC7WW
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>2) If you use a single FIR Hilbert transform for your "Q" branch, make sure
>that the other branch i.e. your "I" is delayed by the "same" group delay,
>i.e. if your Hilbert transform has 39 taps, you need a delay of 39/2 = 19.5
>(use either 19 or 20) taps delay for your "I".
>

>73's
>
>--Johan
>
Thanks Johan,
 The above is what I wanted to know!
 I am using a program called PC-DSP written by Oktay Alkin, I have used it to 
design FIR filters. It is the program that Jon Bloom KE3Z described in QEX a 
year ago (it cmes with a book and costs $29).
 Amoungst other things it allows you to design a Hilbert transfor either
using  Parks
Mc Clelland or Fourier.

I was thinkinking of incorporating it into my 8 ary modem on the C50. However
it seems to have enough processing power to work with a larger complex
transform. I guess I could use Goertzel (???) algorithm instead!

Regards Charles
-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------
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On Thu, 13 Jul 1995, WALT DUBOSE - K5YFW wrote:

> 
>         IMHO, we (hams) will have to decide if we want to "build" a
>         modem to fit into a 500 -2100 Hz -6db bandpass or replace the
>         filters in our HF rigs for ones that will be 300 - 3000 Hz.
> 
>         Admittedly those of us interested in high speed HF data
>         transmission will initially be a very small minority. However,
>         I believe once we can show that robust 2400 BPS data can be
>         sent on HF, there will be many clamoring to get this "new"
>         ham technology.  At this point, manufacturers may begin
>         offering an optional wide SSB filter.
> 
>         I would recommend that you (I didn't say we because I'm not
>         doing the "work") begin with a modulation scheme that will
>         fit into a 500 - 2100 Hz bandpass with the ability to expand
>         to a scheme that can use a 300 - 3000 Hz bandpass.

I agree with you that this is the most promising approach. We should 
reduce the number of tones to be able to nicely fit within the available 
bandwidth of standard ham tranceivers. We should make the modem such that 
it would be easy to reconfigure it to work with different number of 
tones. However to have something which is generally useable, it would 
mean that we will have to have a way of distinguishing between a 
transmissions using the full tone set and ones using a reduced tone set.
Perhaps this could be done by using a different number of Doppler tones.

It is rather clear from recent papers that there is trend away from 
the parallel tone modems and towards the single tone modems. I read 
recently a comparison between these types of modems and it was indicated 
that you would need 15 dB more power with a parallel modem than with the 
serial tone modem to achieve an error rate of 1E-3. During this 
comparison both modems were running without ECC.  I nevertheless think we 
are doing the right thing in going for the parallel tone modems for the 
time being as the serial tone modems need rather complex channel 
equalizers and channel quality analysis algorithms. Serial tone modems 
should come when we have got thorough experience with the parallel tone 
ones. 

The ANDVT TACTERM modem is using an EOM (End-Of-Message) sequence that 
was meant to insure a rapid changeover between receive/transmit. Initially 
I though this would have little use for amateur use, but I am now 
wondering if it would be useful after all. It would insure that at the 
end of transmission the receiving station would quickly be able to take 
the link, or to fall back into preamble tracking mode. If not used it is 
possible that an error burst could confuse the receiver and that it would 
stay in data receive mode, while the transmitting station is sending a 
new Doppler/Sync sequence. 

Would this be of any use? Anyone with an opinion?

73's Frode

	Frode Weierud			Phone	: 41 22 7674794
	CERN, SL			Fax	: 41 22 7679185
	CH-1211 Geneva 23, Switzerland	E-mail	: frode@dxcern.cern.ch
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>         IMHO, we (hams) will have to decide if we want to "build" a
>         modem to fit into a 500 -2100 Hz -6db bandpass or replace the
>         filters in our HF rigs for ones that will be 300 - 3000 Hz.

My two cents:

cent #1:
I want to stress that for the multi-tone modem the passband uniformity
is not very much critical. It should accept ripples up to 12-18 dB
(the Tx filter is in must more critical). This is because every tone
occupies small bandwidth and it is being decoded independently.
That if carrier #1 has an amplitude of 10 but carrier #8 only 1
it really doesn't matter that much.
What I see for the FT757GXII is that the SSB filter passes 300-3000 Hz
within maybe 6dB - this you can see with your S-meter while tuning across
a dead carrier (turn on the internal calibrator). Then the post-demodulation
audio filters do the "nasty" job of attenuation the higher frequencies
so on the output the last carrier is 3 times weaker than the "top" one.
But here I don't really care... the noise gets 3 times weaker too,
so the demodulator will experience as many errors as for any other
carrier.

cent #2:
When I was younger :-) I read many book on building SSB tranceivers
and all the SSB filters mentioned there were 2.7 kHz wide - looked to me
like a very standard bandwidth.

>         Admittedly those of us interested in high speed HF data
>         transmission will initially be a very small minority. However,
>         I believe once we can show that robust 2400 BPS data can be
>         sent on HF, there will be many clamoring to get this "new"
>         ham technology.  At this point, manufacturers may begin
>         offering an optional wide SSB filter.

They should just offer a standard 2.7 kHz filter - no need for "wide" :-)
What might be nice however, is the capability to bypass all the pre-modulation
and post-demodulation audio circuits.

>It is rather clear from recent papers that there is trend away from 
>the parallel tone modems and towards the single tone modems.

We should learn the "single tone modem" principles: does it use some sort
of equalizer to remove the effect of multipaths ?

>I read 
>recently a comparison between these types of modems and it was indicated 
>that you would need 15 dB more power with a parallel modem than with the 
>serial tone modem to achieve an error rate of 1E-3.

And what is the reason for such a difference ?
This effect may come from the fact that for a multi-tone modem
you need to transmit with lower average power because the envelope
of the signal is not constant. So was the "power" the tranceiver power
or was this the signal's power on the air ?

>The ANDVT TACTERM modem is using an EOM (End-Of-Message) sequence that 
>was meant to insure a rapid changeover between receive/transmit. Initially 
>I though this would have little use for amateur use, but I am now 
>wondering if it would be useful after all.

As for now I am going to use EOM sequence but different  that the one for
TACTERM. I will transmit random data with the maximum phase error
(45 degrees) with the intention to generate maximum receiver decoder
errors. I hope this will speed up the DCD swith off. If a noise burst
comes right at the EOM, it will only slow down the DCD switch off by
a factor of two.

My code for the DSPCARD4 acquires proper symbol sync. now, and switches
to the data decoding phase. It even decodes the data I only didn't check
yet if the data come out right.

Pawel
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On Fri, 14 Jul 1995 JALOCHA@chopin.ifj.edu.pl wrote:

> 
> cent #2:
> When I was younger :-) I read many book on building SSB tranceivers
> and all the SSB filters mentioned there were 2.7 kHz wide - looked to me
> like a very standard bandwidth.

You are right that was the standard, but with the band conditions getting 
worse there has been a recent trend to make filters with 1.8 to 2.1 kHz 
bandwidth. I think the 1.8 kHz filters are really for the contest 
operators, but more and more rigs appear with the narrow type of SSB 
filter at 2.1 kHz as the standard filter. Pawel, you are getting old ;-)

> 
> They should just offer a standard 2.7 kHz filter - no need for "wide" :-)
> What might be nice however, is the capability to bypass all the pre-modulation
> and post-demodulation audio circuits.

I think this is not a bad idea. It should be possible to switch out the
audio shaping when running the type of digital modes we are talking about.

> 
> We should learn the "single tone modem" principles: does it use some sort
> of equalizer to remove the effect of multipaths ?

Yes, they are using equalizers, but not simple static equalizers. The 
equalizers are adaptive to be able to cope with the randomly changing HF 
channel. They therefore are using RTCE (Real Time Channel Estimation) to 
evaluate the channel and drive the adaptive equalizer. This can be rather 
complex. Some serial tone modems are using special training sequences 
after the preamble which is then analyzed and evaluted by the receiving 
modem. These modems today run around 3000 bps in a 1800 Hz bandwidth, 
QDPSK modulating a single carrier usually at 1800 Hz. The Ecotel modem 
from Telefunken I think is using 1650 Hz as the carrier frequency.

> 
> >I read 
> >recently a comparison between these types of modems and it was indicated 
> >that you would need 15 dB more power with a parallel modem than with the 
> >serial tone modem to achieve an error rate of 1E-3.
> 
> And what is the reason for such a difference ?
> This effect may come from the fact that for a multi-tone modem
> you need to transmit with lower average power because the envelope
> of the signal is not constant. So was the "power" the tranceiver power
> or was this the signal's power on the air ?
> 

This I got from their published S/N ratio versus BER (bit-error rate) 
diagram that showed about 15dB lower S/N figure for the serial tone modem 
for a BER of 1E-3. So I sort of extrapolated that to mean that I would 
need a 15dB stronger signal from the parallel tone modem to get the same 
BER figure, or did I interpret that wrong?

> 
> As for now I am going to use EOM sequence but different  that the one for
> TACTERM. I will transmit random data with the maximum phase error
> (45 degrees) with the intention to generate maximum receiver decoder
> errors. I hope this will speed up the DCD swith off. If a noise burst
> comes right at the EOM, it will only slow down the DCD switch off by
> a factor of two.

That agrees with my idea as well. You method is perhaps a lot easier than 
to try to correlate a PN sequence to detect the EOM. If it does the same 
job correctly why not.

> 
> My code for the DSPCARD4 acquires proper symbol sync. now, and switches
> to the data decoding phase. It even decodes the data I only didn't check
> yet if the data come out right.
> 

I have even heard some rumours that your waveform already have made it on 
the air via HF. I hope we will get some more reports on these trials.

73's Frode
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Charles,



> I am using a program called PC-DSP written by Oktay Alkin, I have used it to 
>design FIR filters. It is the program that Jon Bloom KE3Z described in QEX a 
>year ago (it cmes with a book and costs $29).
> Amoungst other things it allows you to design a Hilbert transfor either
>using  Parks
>Mc Clelland or Fourier.


Sounds like you have it all under control.


>I was thinkinking of incorporating it into my 8 ary modem on the C50. However
>it seems to have enough processing power to work with a larger complex
>transform. I guess I could use Goertzel (???) algorithm instead!
>
                
If I may add my two cents' worth:

Interesting that you should bring this up. Goertzel's method is nice if you
only need a few FFT bins and probably will be OK for what you need. However,
think about this for a minute: When you compare the spectral energy in a
particular bin as measured with an FFT vs. what you get when you use a nice
sharp FIR filter, you will find that the dynamic range, i.e. the magnitude
of your bigest - smallest number, is much smaller for the FFT case, than for
the FIR output. It is not difficult to see why this is the case when one
consider that a frequency bin is made up of many summed brances, all
containing multiplies. A FIR filter, on the other hand, has a very
predictable outcome as far as saturation and dynamic range is concerened,
especially if coefficients have been engineered to sum to "unity" response
in the worst case senario. Why folks don't use them, is because you need to
many taps to make a decent filter bank - DSP's usually run out of clock
ticks. (There are tricks to lower the filter order, but at a cost of much
higher sampling rates. I'll leave it at that for the moment.)

That being the case, and things getting even worse for an integer FFT, you
may want to consider doing the floating point Goertzel. I have seen the
floating point Goertzel in some books. I believe that the 'C50 has some
special instructions that helps out doing floating point? This should
already help a lot for weak signals. 


Good luck with your project.

--Johan, KC7WW
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>On Thu, 13 Jul 1995, WALT DUBOSE - K5YFW wrote:
>
>> 
>>         IMHO, we (hams) will have to decide if we want to "build" a
>>         modem to fit into a 500 -2100 Hz -6db bandpass or replace the
>>         filters in our HF rigs for ones that will be 300 - 3000 Hz.
>> 
>>         Admittedly those of us interested in high speed HF data
>>         transmission will initially be a very small minority. However,
>>         I believe once we can show that robust 2400 BPS data can be
>>         sent on HF, there will be many clamoring to get this "new"
>>         ham technology.  At this point, manufacturers may begin
>>         offering an optional wide SSB filter.
>> 
>>         I would recommend that you (I didn't say we because I'm not
>>         doing the "work") begin with a modulation scheme that will
>>         fit into a 500 - 2100 Hz bandpass with the ability to expand
>>         to a scheme that can use a 300 - 3000 Hz bandpass.
>

In a document that I received from Phil Karn, it describes in a fair amount
of detail, how one outfit did their own 16-tone MIL-STD-188 modem. They also
had to deal with this same problem of using readily-available SSB rigs.
Their solution was to use an audio band 935 - 2585 Hz for the tones.

>I agree with you that this is the most promising approach. We should 
>reduce the number of tones to be able to nicely fit within the available 
>bandwidth of standard ham tranceivers. We should make the modem such that 
>it would be easy to reconfigure it to work with different number of 
>tones. However to have something which is generally useable, it would 
>mean that we will have to have a way of distinguishing between a 
>transmissions using the full tone set and ones using a reduced tone set.
>Perhaps this could be done by using a different number of Doppler tones.
>
>It is rather clear from recent papers that there is trend away from 
>the parallel tone modems and towards the single tone modems. I read 
>recently a comparison between these types of modems and it was indicated 
>that you would need 15 dB more power with a parallel modem than with the 
>serial tone modem to achieve an error rate of 1E-3. During this 
>comparison both modems were running without ECC.  I nevertheless think we 
>are doing the right thing in going for the parallel tone modems for the 
>time being as the serial tone modems need rather complex channel 
>equalizers and channel quality analysis algorithms. Serial tone modems 
>should come when we have got thorough experience with the parallel tone 
>ones. 

I also believe that there is no question that a single tone system at low
baud rate will outperform a parallel tone system (in terms of BER for any
given s/n). However, in the end it becomes a tradeoff between speed and
robustness. The parallel modem will certainly have the advantage for speed.
I think one have to be careful when reading papers about these things
without normalizing everything to the same units (BER for given S/N at
bits/second/hertz). This is confusing.


>
>The ANDVT TACTERM modem is using an EOM (End-Of-Message) sequence that 
>was meant to insure a rapid changeover between receive/transmit. Initially 
>I though this would have little use for amateur use, but I am now 
>wondering if it would be useful after all. It would insure that at the 
>end of transmission the receiving station would quickly be able to take 
>the link, or to fall back into preamble tracking mode. If not used it is 
>possible that an error burst could confuse the receiver and that it would 
>stay in data receive mode, while the transmitting station is sending a 


In an FEC situation, especially where variable length messages are sent,
every little bit of framing/blocking information is helpful to the remote
decoder. In AMTOR FEC, for example, there is such a "go back to standby"
sequence sent at the end of the transmission. It is repeated several times
and only one of those is needed to get the remote to act on. If the remote
missed it due to interference, then a rapid succession of errors tells that
it has lost sync, whereupon it goes back to hunt for sync. 

If the sync pre-amble is designed cleverly, it may be possible to write an
algorithm that is hunting for it all the time - a daemon. When it sees it,
it forces a frame reset. As an interesting aside, in Pactor, the designers
choose such a poor sync header, that this is not possible - the remote
decoder have to find frames by brute force search for a valid CRC, i.e. a
whole frame buffer of samples have to searched at every new data sample -
then once the CRC is valid, can one inspect the sync symbol. This is one
reason why the early Pactor units could not do automatic signal detection of
all modes  - there Z80 processor was out of cycles.
 
--Johan
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To: tapr-bb@tapr.org (TAPR-BB mailing), netsig@tapr.org (NETSIG mailing),
        bbssig@tapr.org (BBS SIG mailing), hfsig@tapr.org (HF SIG mailing),
        dsp-93@tapr.org (DSP-93 Build), aprssig@tapr.org (BBS SIG mailing),
        amsat-bb@amsat.org (AMSAT BB Mail Group)
Date: Fri, 14 Jul 1995 13:40:11 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1780      


Don't forget --  Friday, July 21st!  Deadline for ARRL DCC Article Submissions
------------------------------------------------------------------------------

* Anyone interested in digital communications is invited to submit a paper for
  publication in the Conference Proceedings.  Articles are welcome on any
  aspect of digital communications.

* Presentation at the Conference is not required for publication. 

* Papers are due by July 21, 1995, and should be submitted to
  Maty Weinberg, ARRL, 225 Main Street, Newington, CT 06111 or via the
  Internet to mweinberg@arrl.org 

* Please contact Maty for detailed format requirements. 

* It is not to late to start writing!

---

If you think you will be late in submitting your paper(s), contact Maty to
arrange details.

---

14th Annual ARRL Digital Communications Conference
September 8-10th, 1995
Arlington, Texas (minutes from DFW airport)

The ARRL Digital Communications Conference is an international forum for
radio amateurs in digital communications, networking, and related 
technologies to meet, publish their work, and present new ideas and 
techniques for discussion.  Presenters and attendees will have the 
opportunity to exchange ideas and learn about recent hardware and 
software advances, theories, experimental results, and practical 
applications. The Digital Communications Conference is not just for 
the digital elite, but for digitally-orientated amateurs of all 
levels of experience. 

For further information:

E-Mail: TAPR@TAPR.ORG
Web   : http://www.tapr.org/tapr
ftp   : ftp://ftp.tapr.org/tapr/95_DCC_Flyer.pdf

------------------------------------------------------------------------
Tucson Amateur Packet Radio
8987-309 E Tanque Verde Rd #337 * Tucson, Az * 85749-9399 * 817-383-0000


From k5yfw@sacdm10.kelly.af.mil Fri Jul 14 15:05:01 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id PAA00705 for <hfsig@tapr.org>; Fri, 14 Jul 1995 15:04:48 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0sWqcq-0001v2C; Fri, 14 Jul 95 14:42 CDT
Message-Id: <m0sWqcq-0001v2C@sacdm10.kelly.af.mil>
Date: Fri, 14 Jul 95 14:42:15 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:469] Re: ANDVT TACTERM Documentation
To: hfsig@tapr.org
X-orig-date: Fri, 14 Jul 1995 10:14:26 -0500
X-orig-from: Frode Weierud <frode@dxcern.cern.ch>
X-orig-message-ID: <Pine.ULT.3.91.950714162737.7711A-100000@dxcern.cern.ch>

The Thread sez:
> > They should just offer a standard 2.7 kHz filter - no need for "wide" :-)
> > What might be nice however, is the capability to bypass all the pre-modulation
> > and post-demodulation audio circuits.
>
> I think this is not a bad idea. It should be possible to switch out the
> audio shaping when running the type of digital modes we are talking about.
>

        This is a reality check:

        Getting a manufacturer to "custom" build an HF rig to fit the
        needs of a small groups of users (like us) is unlikely...Why?
        Because I dare say that few HF rig manufacturers build more
        than 50,000 of any certain model (at an average of $600US,
        that's $30,000,000 in wholesale sales).

        It is more than likely that they are building HF rigs with the
        filters they have to support the large DX community where a
        narrow bandpass is desirable.

        I believe you must design a modem that can be used with the HF
        rigs on the market (today) and prove the modems worth before
        you will find manufactures building and selling HF rigs with
        the filtering/audio response you/we desire


> I have even heard some rumors that your waveform already have made it on
> the air via HF. I hope we will get some more reports on these trials.
>

        If you mean 39 or 16 parallel tone modems (such as in the
        TACTERM), there are many U.S. DoD agencies and some
        commercial HF users carrying on HF data communications using
        these modem protocols.  I have heard what sounds like strong
        noise peaks on HF and suspect that many of these are the
        multi-tone and serial tone modems at work.


73,  Walt
From willi_r@mail.uwlax.edu Fri Jul 14 19:03:03 1995
Received: from mail.uwlax.edu (mail.uwlax.edu [138.49.128.137]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id TAA04178 for <hfsig@tapr.org>; Fri, 14 Jul 1995 19:02:57 -0500
From: willi_r@mail.uwlax.edu
Received: from dial03.wwrdc.uwlax.edu by mail.uwlax.edu;
          id AA10355; NX5.67d/42; Fri, 14 Jul 95 19:01:55 -0500
Date: Fri, 14 Jul 95 19:01:55 -0500
Message-Id: <9507150001.AA10355@mail.uwlax.edu>
X-Sender: willi_r@mail.uwlax.edu
X-Mailer: Windows Eudora Version 1.4.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
Subject: CLOVER II vs. Pactor II

There were two things holding me back from making a decision to "invest" in
new hf modem hardware. 1) Legal operation of automatic and semi-automatic
operation in the U.S. and 2) Which is the best hf mode for hi speed transfer
under all condx whether for highest speed or best thruput under
deteriorating condx.

Well #1 is now settled and legal here in U.S.A.

But #2 is still up in the air.

Anybody have any preliminary information on what the comparison will be? OK,
how about any opinions? Pactor II sounds better than CLOVER II in that it
may have faster thruput and better weak signal abilities, but we need some
tests. Surely, some of you folks who are the worlds top leaders in hf issues
are either doing some tests yourself or know of others. This would be
bugging me to no end if I had the equipment. I would have to know.:-)

The alternative is for one of the digital ham companies to come out with a
unit that will do both modes or better yet, do one now and have a guaranteed
upgrade path for a reasonable price (like no more than 100 bux) to the other
mode within a year or so.
I have no idea of the approximate cost there is to license these modes, but
if there was a DSP modem that had the horsepower and the support of the 3rd
party software authors to make it work with Winlink and similar
connectivity, I know I would be a buyer at the 500-700 bracket.

I did ask HAL about this but they said (in a very nice way) that they could
not commit to this concept. Maybe licensing is really high priced but find
it hard to believe it could be over 20-30 bux per license. Am I living in
fantasyland?

Wonder if the TAPR DSP-93 board could handle these new modes? Wonder if it
could get the support like the HAL boards do? I sure would not have a
problem with paying a modest price for embedded call software for TAPR
software (50 bux or so) similar to what the IDRA (International Digital
Radio Association) formerly the ADRS does with their rather successful software.

Rick, KV9U

From frode@dxcern.cern.ch Sat Jul 15 10:41:13 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id KAA10367 for <hfsig@tapr.org>; Sat, 15 Jul 1995 10:41:09 -0500
Received: from dxcern.cern.ch by dxmint.cern.ch
	id AA00465; Sat, 15 Jul 1995 17:41:07 +0200
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA22276; Sat, 15 Jul 1995 17:41:02 +0200
Date: Sat, 15 Jul 1995 17:41:02 +0200 (MET DST)
From: Frode Weierud <frode@dxcern.cern.ch>
To: hfsig@tapr.org
Subject: Re: [HFSIG:473] Re: ANDVT TACTERM Documentation
In-Reply-To: <m0sWqcq-0001v2C@sacdm10.kelly.af.mil>
Message-Id: <Pine.ULT.3.91.950715173400.22055B-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 14 Jul 1995, WALT DUBOSE - K5YFW wrote:

> 
>         I believe you must design a modem that can be used with the HF
>         rigs on the market (today) and prove the modems worth before
>         you will find manufactures building and selling HF rigs with
>         the filtering/audio response you/we desire

I agree we will probably not get the rig manufacturers to tailor their 
rigs to our needs. What I had in mind was simply a data input/output like 
you now find on the new VHF/UHF rigs for packet radio. This data I/O will 
simply bypass the audio shaping that you have in most rig. It will not 
solve the problem with lousy filters, but it should improve things slightly.

> > I have even heard some rumors that your waveform already have made it on
> > the air via HF. I hope we will get some more reports on these trials.
> >
> 
>         If you mean 39 or 16 parallel tone modems (such as in the
>         TACTERM), there are many U.S. DoD agencies and some
>         commercial HF users carrying on HF data communications using
>         these modem protocols.  I have heard what sounds like strong
>         noise peaks on HF and suspect that many of these are the
>         multi-tone and serial tone modems at work.
> 

Yes, I have heard several of these transmissions. They are on every day.
What I really meant with my remark is that Pawel's multitone modem has 
made it on HF. A few hams are now actively testing his modem on VHF and 
HF. Just to let you see that things are moving extremely fast ahead.

73's Frode


	Frode Weierud			Phone	: 41 22 7674794
	CERN, SL			Fax	: 41 22 7679185
	CH-1211 Geneva 23, Switzerland	E-mail	: frode@dxcern.cern.ch

From k5yfw@sacdm10.kelly.af.mil Sun Jul 16 18:56:57 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id SAA17449 for <hfsig@tapr.org>; Sun, 16 Jul 1995 18:56:53 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0sXdTi-00016QC; Sun, 16 Jul 95 18:52 CDT
Message-Id: <m0sXdTi-00016QC@sacdm10.kelly.af.mil>
Date: Sun, 16 Jul 95 18:52:05 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Parallel vs Serial Tone Modems
To: hfsig@tapr.org

Having used both parallel and serial tone MIL-STD-188-110A modems, I
must admit that the serial tone modem appeared to be more robust.
However, I really wonder if we (hams) need that robustness.  We're
talking about signals way down in the noise...channelized communications
with known stations on the channel.  I'm not sure this is really
needed on the hambands.  It would come in handy during the midst of a
hurricane where the noise level is very high;  but, we generally use
slow speed CW (5-10 wpm) done here on the Texas Gulf Coast.

I do not mean to stifle efforts in developing a serial tone modem...
I'm just trying to be a little practical.  As we say at Kelly AFB,
"why buy a Cadillac when a Chevrolet will do".

How about both...then we can "have our cake and eat it too".

73,  Walt
From k5yfw@sacdm10.kelly.af.mil Sun Jul 16 19:02:23 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id TAA17509 for <hfsig@tapr.org>; Sun, 16 Jul 1995 19:02:16 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0sXdYu-0001m6C; Sun, 16 Jul 95 18:57 CDT
Message-Id: <m0sXdYu-0001m6C@sacdm10.kelly.af.mil>
Date: Sun, 16 Jul 95 18:57:27 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:475] Re: ANDVT TACTERM Documentation
To: hfsig@tapr.org
X-orig-date: Sat, 15 Jul 1995 10:45:19 -0500
X-orig-from: Frode Weierud <frode@dxcern.cern.ch>
X-orig-message-ID: <Pine.ULT.3.91.950715173400.22055B-100000@dxcern.cern.ch>

In Frode's message of 15 Jul 1995 at 1045 CDT, he writes:
> What I really meant with my remark is that Pawel's multitone modem has
> made it on HF. A few hams are now actively testing his modem on VHF and
> HF. Just to let you see that things are moving extremely fast ahead.
>
> 73's Frode


         In the local youth vernacular.....C o o l !  -- wdd
From chbrain@dircon.co.uk Mon Jul 17 01:31:37 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id BAA24608 for <hfsig@tapr.org>; Mon, 17 Jul 1995 01:31:32 -0500
Received: by felix.dircon.co.uk id AA13339
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 17 Jul 1995 07:31:27 +0100
Message-Id: <199507170631.AA13339@felix.dircon.co.uk>
Received: from ad044.pool.dircon.co.uk(193.128.231.44) by amnesiac via smap (V1.3)
	id sma013331; Mon Jul 17 07:30:56 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 17 Jul 1995 05:40:36 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:476] Parallel vs Serial Tone Modems


>I do not mean to stifle efforts in developing a serial tone modem...
>I'm just trying to be a little practical. 
>73,  Walt
>
>
Hey,
 Walt we do things because they are there!!! Seriously I have been waiting for
a discussion on serial tone modems. A simple slow speed modem appears to
be quite do-able. The main problem is I think is  the probable requirement
to use
multiple DSPs. 
 I have been reading about the equalisers used in mobile radio modems, I guess 
the real difference is the actual multipath delays are much greater
therefore longer
equalisers are needed for H.F.
 Whether we use a training sequence or decision directed I cannot guess.
However it may well be that a slow < 1kbit/s modem is more suitable for the ham 
environment especially something that is proof against those pesky CWers! 

Something like a 300 baud modem would be interesting with a simple equaliser
in front of it.

As far as receivers are concerned a nice project would be to take an I.F signal
down convert it to say 10Khz then demodulate using DSP. I will have to 
investigate my TS850 as it does something like that for it's external DSP unit.
(Although it just filters).

Another thing would be an intelligent VOX with compression done in DSP 
could event have an expander at the far end.

I must admit I have learn't a lot the last few months from this news group, my 
8ary modem is proceeding it has been re-written a couple of times due to 
my improving knowledge. My main problem currently is gaining and tracking
bit sync. The sync has to lock as fast as possible. It should also have the
ability to re-sync to a colliding signal this of course causes a problem!
The technique I am using is to divide the tone with the highest power with 
that of the others. This produces a nice triangle wave. I then use an early/late
gate to find the peak. This locks the NCO (thats the bit I can't get to work
yet)
the NCO then triggers an integrate and dump. At the end of the period a decision
is made as to which tone was received. 


Regards Charles 
-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From kurpiers@zeus.uet.e-technik.th-darmstadt.de Mon Jul 17 02:27:25 1995
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id CAA25375 for <hfsig@tapr.org>; Mon, 17 Jul 1995 02:27:11 -0500
Received: from zeus (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th-darmstadt.de with SMTP id AA21050
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Mon, 17 Jul 1995 09:26:59 +0200
Received: from hades (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus (8.6.9/8.6.9-HRZ) with ESMTP id JAA17795 for <hfsig@tapr.org>; Mon, 17 Jul 1995 09:26:58 +0200
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de>
Received: (kurpiers@localhost) by hades (8.6.9/8.6.9-HRZ-Fwd2.0) id JAA15524 for hfsig@tapr.org; Mon, 17 Jul 1995 09:26:58 +0200
Message-Id: <199507170726.JAA15524@hades>
Subject: Re: Parallel vs Serial Tone
To: hfsig@tapr.org
Date: Mon, 17 Jul 1995 09:26:58 +0200 (MESZ)
In-Reply-To: <199507170631.AA13339@felix.dircon.co.uk> from "Charles Brain" at Jul 17, 95 01:34:38 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2753      

Hi all!

Thank you very much for the pleasant discussions during the last
weeks. I like to contribute to the discussion of seriell vs. parallel
type modems. This discussion is quite popular now in Germany
an Europe as we are going to use a parallel type modem
(coded OFDM) for broadcasting digital audio (DAB). There were
several arcticles stating that single carrier transmissions are
better in general. As our institute here does research work on
OFDM this is of course not our opinion. Looking at HF there
were a few comparisions of single tone modems to parallel tone ones.
All this papers have in common that the modems are compared using
no coding at all. This is not fair at all, as single carrier modems
need a demodulation scheme that is somehow a form of  coding.
I think this is due to the fact that parallel tone modems
are older than single carrier ones and therefore usually do
not use advanced signal processing algorithms or coding. If you
look at recent papers about parallel tone modems there is still
enough to do.
The only real drawback when using parallel tone modems is the
limited mean power with peak power limited equipment. If you are
using proper FEC schemes, both types should be comparable even at low
BER. From the implementations point of view you need a considerebly
higher complexity for single carrier modems than for parallel ones.
If someone is interested in information look for articles
from Clark, A.P. or for: Clark, A.P.: Adaptive Detectors for Digital
Modems. Pentech Press, London 1989. He discusses several very interesting
aspects of single carrier transmission on HF.

So far no one has mentioned the advantages of parallel tone modems
other than the relaxed complexity. We have a back channel from the
receiving to the transmitting side which we can use for informing
the transmitter of the channel conditions. The receiver could i.e.
tell the transmitter, that one frequency bin is jammed, so that
the transmitter can leave this bin empty. Try this with a single
carrier modem... 

BTW. Can anybody make me a copy of the Mil-STD things? It is
not so easy to get these things in Germany. Or is there maybe
a Gopher server like for the CCITT?

Alexander DL8AAU

-- 
*----------------------------------+---------------------------------------*
|      Alexander F. Kurpiers       |                                       |
| Institut f. Uebertragungstechnik | Voice: +49-6151-162369                |
|    u. Elektroakustik             | Fax  : +49-6151-165545                |
| Merckstrasse 25                  | EMail: a.kurpiers@uet.th-darmstadt.de |
| D-64283 Darmstadt (Germany)      | Hamradio: dl8aau@db0eam.#hes.deu.eu   |
*----------------------------------+---------------------------------------*


From frode@dxcern.cern.ch Mon Jul 17 03:22:18 1995
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id DAA26224 for <hfsig@tapr.org>; Mon, 17 Jul 1995 03:22:13 -0500
Received: from dxcern.cern.ch by dxmint.cern.ch
	id AA12733; Mon, 17 Jul 1995 10:22:10 +0200
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
	id AA05223; Mon, 17 Jul 1995 10:22:08 +0200
Date: Mon, 17 Jul 1995 10:22:06 +0200 (MET DST)
From: Frode Weierud <frode@dxcern.cern.ch>
To: hfsig@tapr.org
Subject: Re: [HFSIG:471] Re: ANDVT TACTERM Documentation
In-Reply-To: <9507141724.AA15857@ucs.orst.edu>
Message-Id: <Pine.ULT.3.91.950717092450.2226A-100000@dxcern.cern.ch>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 14 Jul 1995, Johan Forrer wrote:

> 
> In a document that I received from Phil Karn, it describes in a fair amount
> of detail, how one outfit did their own 16-tone MIL-STD-188 modem. They also
> had to deal with this same problem of using readily-available SSB rigs.
> Their solution was to use an audio band 935 - 2585 Hz for the tones.

Yes, this is the 16-tone modem from MIL-STD-188-110A, Appendix A. The 
interesting thing is that the ANDVT TACTERM modem is based on the 39 tone 
modem described in Appendix B. They are using the same preamble tones for 
both Doppler Preamble and Frame Sync preamble. The length of the 
preambles are not exactly the same though. And the 16 data tones have 
been extracted from the 39 tone set.

> 
> I also believe that there is no question that a single tone system at low
> baud rate will outperform a parallel tone system (in terms of BER for any
> given s/n). However, in the end it becomes a tradeoff between speed and
> robustness. The parallel modem will certainly have the advantage for speed.
> I think one have to be careful when reading papers about these things
> without normalizing everything to the same units (BER for given S/N at
> bits/second/hertz). This is confusing.

I agree it sometimes sounds confusing. I have no garantie that they did 
the normalization correct in this paper I referred to, but the results of 
the modem tests was plotted in the same diagram and as they used SNR 
instead of Eb/No (bit energy to noise-power spectral energy) I supposed 
they had normalized for bit rate and bandwidth. I would like to invite 
all of you to have a close look at Bernard Sklar's tutorial "Defining, 
Designing, and Evaluating Digital Communication Systems", IEEE 
Communications Magazine, Vol. 31, No. 11, Nov. 1993, pp.92-101. I find 
this an excellent paper in clarifying a somewhat convoluted subject.

As I have already put on my teaching hat I will give you a few other 
literature pointers as well. First of all I should like to mention the 
paper by Joseph M. Perl, "Channel Coding in a Self-Optimizing HF Modem", 
Proceedings of the 1984 International Zurich Seminar on Digital 
Communications, March 6-8, 1984, (IEEE Catalog No. 84CH1998-4), 
pp.101-106. This is an interesting approach for designing an adaptive and 
optimizing HF modem. It can choose between four different modulation 
types: DPSK, DQPSK, FSK and MFSK, while the number of tones are equal or 
less than 49, baud rate equal of less than 100 Baud, in band diversity, 
error correcting codes (Golay 1/2; Majority, Convolutional 1/2, 1/3, 
1/4), interleaving delay equal or less than 4.5s, with hard and soft 
Viterbi decoder.

The trick is of course the Link Quality Evaluation (LQE) which is based 
on analysis of the received information or on the preamble tones, hence 
no special link quality signaling is needed. The channel estimation 
does not take more than about 8% of DSP processor's resources. The 
channel evaluation techniques used are described in another paper, which 
I don't have the reference to where I am sitting at the moment. I can 
come back with that if there is an interest.

Another paper that almost answers Pawel's questions about optimum symbol 
rates etc. is: Doron Rainish and Jospeh M. Perl, "Generalized Cutoff Rate 
od Time- and Frequency-Selective Fading Channels", IEEE Trans. on Comm., 
Vol. 37, No. 5, May 1989, pp.449-467. They look at optimal code rate and 
symbol element duration for MFSK and MDPSK in various HF channels. They 
also look at optimal guard time.  An interesting thing is the special 
case for MDPSK over the CCIR HF channel, where the optimal guard times 
equals the multipath spread and is independant of SNR. The paper is at 
times rather heavy, but the final plots are very clear. 

The question of guard time is an interesting one. Ralph is rather 
sceptical to the value of using guard time, and the paper above also 
shows that the real value is somewhat dubious. One thing is sure and that 
it is a loss of signalling energy and that has to be weighted against 
what effect it can have on combating multipath spread.

The question about what type of modem which is the optimal for amateur 
use is very difficult to answer as we have very diverse needs. Some of us 
only want to have a chat now and then and then a MFSK (a la Piccolo) 
modem should assure good performance under almost all conditions, while 
others are interested in moving large amount of data at high speed to tie 
together packet radio networks etc. For the high speed use both parallel 
tone and serial tone modems have their place and as Peter Reynolds', KE4BAD,
paper "HF Channel Simulator Tests of Clover", QEX, December 1994, pp.7-12 
showed a serial tone modem like the one described in STANAG 4285 is a 
very serious contender. It clearly beats the Clover waveforms.

73's Frode

	Frode Weierud			Phone	: 41 22 7674794
	CERN, SL			Fax	: 41 22 7679185
	CH-1211 Geneva 23, Switzerland	E-mail	: frode@dxcern.cern.ch

From JALOCHA@chopin.ifj.edu.pl Mon Jul 17 05:32:08 1995
Received: from nms (nms.cyf-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id FAA26822 for <hfsig@tapr.org>; Mon, 17 Jul 1995 05:32:02 -0500
From: JALOCHA@chopin.ifj.edu.pl
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I am very pleased to annouce that I have made a useable modem's code
with KISS interface.

Just to remind you:
My modem uses 15 tones spaced at 150 Hz. Each tone is DQPSK modulated
at 100 baud. Total bit rate is thus 15*100*2 = 3000 bps.
The modem auto-tunes to incoming packets within at least +/- 75 Hz
( +/- 100 Hz is the absolute limit ).
Optionally you can activate simple FEC: for every 11 data bits you add 4
and afterwards you can correct single bit errors.
Interleave is the other option: any reasonable factor can be specified.

The modem is still missing frequency and symbol timing tracking during
the data decoding phase.
My initial tone's phases aren't very good either so I get
peak/RMS = 4 (12 dB).

So far I have only made a simple loopback tests and I get the following
results:

FEC off, S/N = 13 dB => 3/4 of 230 byte packets get through

FEC on, S/N = 7 dB  => 3/4 of 230 byte packets get through

Don't take these results too serious, as the noise spectrum wasn't
very flat...
Noise and RMS measurements were done with a soundcard by recording
the noise/signal and computing the RMS off-line.
Packet loss rate was measured with JNOS by sending out regular beacons
and looking up the number of received packets.

There is a hope that the first on-air tests will be done this week
by Timo and Joni from Finland.

Pawel
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Hi Rick,


You pose some difficult questions. The probably are aware of a lot of 
claims are presently being made as well as some degree of 
personalities involved. I do not wish to add to the confusion, however, 
just add my two cents worth.

I am of the opinion, at least as far as I can tell of this group 
of technically-minded participants, that all are interested in something 
that shows potential, however, without some common-sense evaluation 
or theoretical proof, who really knows what is better?

There was a posting about a year or so ago from Rolf Sommerhalder about 
several systems that werer compared using an HF channel simulator - these 
included Pactor I and Clover II. There also was an interesting paper in QEX 
a while ago, mostly on Clover's capabilities - also done using a channel 
simulator. It may be worth your while finding these and perhaps it will give 
you a bit further insight - this the way how modems should be 
evaluated. From this you would want to see the BER vs. S/N curves. 

IMHO, the designers of Pactor I must be credited for clever innovation, 
basically on what was available at the time, i.e., 100 baud FSK. The 
protocol does, however, have a few snags. (a) a totally inappropriate 
synchronisation method, (b) no automatic link re-establishment after 
failure, (c) a flawed fall-back to lower rate when conditions are really 
bad. The claims of the designers regarding memory ARQ gain, was based on 
AWGN and not quite appropiate. Implementation of memory ARQ by other 
licencees not using any form of A/D is rather amusing. Pactor II has 
several innovative features such as stronger ECC and a new modulation. With 
this innovation comes new challenges - frequency accuracy needs closer 
tolerances - fallback procedures are getting more complex. Time will tell 
how practical it all will work out. I can only guess the results when a 
device like this is being used by a complete non-technical novice.

I don't know how many folks have follwed the evolution of Clover from the 
early days of CCW? Again, my personal opinions - I have always have 
had a great deal of respect for Clover's principles and believe it to be 
superior to anything that we have had on the ham bands. That 
is due to its modulation format, ECC, and also the transmission 
protocol is well engineered.

Of the two, Pactor II and Clover II, my personal opinion is that the 
Clover modulation is superior to Pactor II's (I think it may be possible 
to prove it theoretically by deriving each error function (Marqum Q)). 
Pactor II, however, probably have a stronger ECC. We will have to see how 
these two utilities plays off against each other, i.e., Clover's 
time/frequency diversity principles against Pactor II's convolution code.

I still am aking the unpopular question:  why have we not seen a 
technical disclosure of either Clover or Pactor's such as we have seen done 
for G-TOR for example (published in full in the 1994 DCC proceedings). I 
mean at a level sufficient that amateurs can evaluate how things are 
really working. 

Sorry that I cannot offer a clear answer - I am afraid I only add to 
the confusion.

73's

--Johan

   









As far as I can see, not many of the particpants in this net will jump in 
to buy, but rather 
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Charles,

In your message of 17 Jul 1995 at 0134 CDT, you write:
>
> >I do not mean to stifle efforts in developing a serial tone modem...
> >I'm just trying to be a little practical.
> >73,  Walt
> >
> >
> Hey,
>  Walt we do things because they are there!!! Seriously I have been waiting for
> a discussion on serial tone modems. A simple slow speed modem appears to
> be quite do-able. The main problem is I think is  the probable requirement
> to use
> multiple DSPs.

        Rgr Rgr...don't let me slow you down and if I can duplicate
        your effort, rest assured I will.

>  I have been reading about the equalisers used in mobile radio modems, I guess
> the real difference is the actual multipath delays are much greater
> therefore longer
> equalisers are needed for H.F.
>  Whether we use a training sequence or decision directed I cannot guess.
> However it may well be that a slow < 1kbit/s modem is more suitable for the ham
> environment especially something that is proof against those pesky CWers!
>
> Something like a 300 baud modem would be interesting with a simple equaliser
> in front of it.

        No doubt about the need for a *very* robust modem for those
        occasions when the noise is high and/or the signal is low and
        you need to get a message thru, then this type of modem would
        be nice.  Its something we might use here on the Texas Gulf
        Coast during a hurricane.

>
> As far as receivers are concerned a nice project would be to take an I.F signal
> down convert it to say 10Khz then demodulate using DSP. I will have to
> investigate my TS850 as it does something like that for it's external DSP unit.
> (Although it just filters).
>
> Another thing would be an intelligent VOX with compression done in DSP
> could event have an expander at the far end.
>
> I must admit I have learn't a lot the last few months from this news group, my
> 8ary modem is proceeding it has been re-written a couple of times due to
> my improving knowledge. My main problem currently is gaining and tracking
> bit sync. The sync has to lock as fast as possible. It should also have the
> ability to re-sync to a colliding signal this of course causes a problem!
> The technique I am using is to divide the tone with the highest power with
> that of the others. This produces a nice triangle wave. I then use an early/late
> gate to find the peak. This locks the NCO (thats the bit I can't get to work
> yet)
> the NCO then triggers an integrate and dump. At the end of the period a decision
> is made as to which tone was received.
>
>
> Regards Charles
> -- -----------------------------------------------------------------
>   "projects don't slip, they just catch up with reality"
>
>   Charles Brain (G4GUO)
>   Chelmsford, Essex.
>   E-mail chbrain@dircon.co.uk
>   POTS +44 (0)1245 353221
>   FAX  +44 (0)1245 275448
> -------------------------------------------------------------------
>

Keep up the good work and say HOWDY, to all tha hams at the
Chelmsford Radio club and the Marconi folks.  I really miss G0AEH,
Albert, from Blackmoore/Hook-End...he was a very nice fellow.
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Johan...

On Mon, 17 Jul 1995 11:44:13 -0500, you wrote:

>I am of the opinion, at least as far as I can tell of this group
>of technically-minded participants, that all are interested in something
>that shows potential, however, without some common-sense evaluation
>or theoretical proof, who really knows what is better?

I just want to add some thoughts of my own...

A commonly held opinion of hams is "What's my discount"...  Hams always
want the cheapest, bestest thing they can get...  Several things come into
play here...  Cheap, if it works, will always win out over expensive...
This has been, IMHO, the reason Clover has not taken off...  This new
Clover board may be the breakthrough that Clover needs...  But $395 is 
still a lot...  Look at the DigiCom packet stuff for the Commodore...  That 
stuff is still running around the world...  Good and cheap...  Look at the 
success of BayCom...  Look at the success of Pactor I...  I tuned around 
recently on a weekend on 20 meters and Pactor I is the only thing that I 
heard...  Why was it successful...  It was pretty cheap and everyone had 
it...  Once AEA and MFJ and Kantronics all put it in their products it 
became a standard...  Until somebody besides HAL sells Clover it will never 
gain popularity, even if it is 1000 times better...  G-TOR has a good
chance since it is being licensed...

None of this stuff is going to ever be popular on Ham Radio unless someone
opens up the licensing...  We would probably not have packet radio now if
it hadn't been for TAPR...  All the current popular modes on ham radio are
open technically and copyright wise...  The great success of the IBM PC had
largely to do with the open architecture of the buss...  The only good
thing IBM ever did for the computer community, in my mind...  (Don't flame,
I won't read or respond...)

>I still am aking the unpopular question:  why have we not seen a
>technical disclosure of either Clover or Pactor's such as we have seen done
>for G-TOR for example (published in full in the 1994 DCC proceedings). I
>mean at a level sufficient that amateurs can evaluate how things are
>really working.

One of the things that I hope will come out of this group is a definitive 
statement concerning a good CHEAP way for amateurs to communicate digitally
via HF...  I think that we are on the way...  I hope when something is
decided that TAPR might pick up the ball again...  I think that using the
sound cards is a BIG step forward...  This group ought to be the ones to
put together the digital basis for HF communications into the 21st
century...   Something that any moderately technical ham can get running
for less than $200...

I have an old HAL RTTY modem, a CRI-200, I found at a hamfest for $45...
That and BMK Multy got me on RTTY, PACTOR, AMTOR for less than the $200...
I would do it again...  We need this kind of thing for advanced HF digital
and I am convinced that it is do-able...  Johan is there with the PC-TOR
stuff, but it needs to be with the more robust error correcting and higher
data speeds...  Lets keep pushing forward...!!!

In the mean time Internet Relay Chat and E-Mail on the Internet is taking
over the role of digital communications via ham radio...  And on IRC you
don't have to know the code or take an FCC test...  There are thousands of
technically competent folks using that now, who could be hams...  There's
even a ham radio area (#hamradio) on IRC, populated by a BOT and people...

We need to move forward or ham radio is going to flounder and forever be
gone...!!!  I'm on the Internet every day and on ham radio very rarely...
I don't want to see it go, but I think that it's demise is getting 
closer...

73...  Marv...  K4BVG

In the midst of great joy, do not promise anyone anything.  In the midst of
great anger, do not answer anyone's letter.    - Chinese Proverb

-- Marv Uphaus -- muphaus@cris.com -- finger for PGP public key --
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Here is a reference for those of you interested in comparing the COFDM
and single-tone techniques which Alexander, DL8AAU, discussed in his
recent posting.

     H. Sari, G. Karam, I. Jeanclaude, "Transmission techniques
     for digital terrestrial TV broadcasting", IEEE Communications
     Magazine, February 1995, pp.100-109.

The authors begin with an overview of OFDM and channel equalization.
It turns out that OFDM is very similar to a single-tone system using
frequency-domain equalization.  This was interesting since most
equalization techniques I have seen (including those used in the
single-tone MIL-STD modems) work in the time-domain.  In retrospect
I guess it shouldn't be surprising that equalization can be done in
the frequency-domain considering all the time-frequency dualities
in Fourier analysis.

Next the authors have a simple derivation showing why OFDM is
extremely sensitive to frequency offsets.  I accidentally ran into
this when I mis-typed a sampling frequency in the peak-to-RMS
amplitude simulations I worked on a few months ago.  Energy spilling
into adjacent FFT bins like they were leaky buckets!  I hate when 
that happens.  Pawel seems to have discovered this empirically; which
is why his modem has auto-tuning.

In the next section the authors present the results of some computer
simulations showing that losses produced by frequency offsets and
power backoff (due to the high peak amplitudes) in OFDM produce BERs
much larger than those of an equalized simgle-tone system.

One observation the authors make is that frequency selective fading
produces an irreducible BER in OFDM systems not using forward error
correction (FEC).  Which leads to their last results showing that an
OFDM system with FEC, coded OFDM (COFDM), can produce BERs identical
to or slightly better than an equalized single-tone system (without
FEC).  At the very least this shows the power, and necessity, of FEC!

One unanswered question is the relative implemention complexity
(DSP cycles) of COFDM versus single-tone modulation with frequency-
domain equalization.  All the time domain equalizers I have seen are 
tremendous cycle hogs (not the Harley-Davidson kind either).  I
wonder if frequency-domain equalization is any easier.  Can a DSP
sound card handle it?

It also seems that performance of the single-tone modem could be
improved by adding FEC.  Of course, this would require even more DSP
cycles, unless the host computer does the FEC decoding.

COFDM would seem to have the initial advantage in reduced complexity
(please correct me if this is wrong).  Past examples of working 
systems show that it can be done.  As long as the carrier tracking
and high peak power limitations can be overcome it looks like this 
could produce a robust system.

As others have noted a fairly inexpensive, robust, moderate speed
HF modem will be a big step forward.  Basing it on DSP just means it 
can be improved without buying new hardware.  Keep up the good work!


Eric, N2NNP

    .:::.  .:::.  .:::.
   :'     :'     :'              Eric E. Silbaugh
  :::.   :::.    ':.           esilbaug@afit.af.mil
 ::     ::         ':. 
 ::     ::           ::   All standard, non-standard, and
  '::::::::::::::::::'       MIL-STD disclaimers apply
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Hi all,

Attached is a bit of information that should be of importance to all.
Thanks to Rick for allowing me to post it:


=========================================================================
Hi Rick,

I'm pleased that you bring this up as I was in the process of doing it 
myself. This is a topic that should be addressed rather carefully and 
diplomatically - historically there have been great differences of opinion 
about this very topic.  

>Johan,
>I have been following the HFSIG and one thing bothers me.  With all the 
>talk of total occupied bandwidth what is the limit for HF?  Do we really 
>have SSB type bandwidths to play with?  For some reason I thought we were 
>limited to 300 baud and a maximum peak to peak deviation of 1 KHz under 
>30 MHz.  By Carson's rule this is approximately 
>2*(500+300)=1.6 KHz of bandwidth.  Is this right?


Correct - that is roughly how I interpret part 97 as well. One further 
point that is often forgotten, is that part 97 also specifies which code 
alphabet (i.e. ASCII or BAUDOT). The latter has clearly been violated by 
modern digital modes - Clover for instance by using ECC, Pactor and G-TOR 
when using data compression - just a technicality that have never legally 
been challenged. This, however, is if you interpret the law to the 
letter. Clearly, however, the mentioned violations are not serious, and as 
a matter of fact not intentional encryption. One might argue that it is done 
all the time - that is not how part 97 is written - I suspect 
that the matter about the code alphabets will rest unless challenged. IMHO, 
it will be a total waste of time and resources if it does become a legal 
issue. 

I would rather see that our FCC regulations regarding the digital modes be 
brought up to date with the UK and German regulations, or otherwise to keep 
track with modern technology.   


>Next Question.  If 1.6 KHz is right, why does Clover fit into 500 Hz?  Are 
>we required to use CW type bandwidths?  If not, then why bother with such 
>tight restrictions since wider bandwidth is (probably) easier to use 
>effectively...except for the CW interference problems.
>Thanks
>Rick W6NZK
>-------------------------------------
>Rick Booth
>E-mail: rick@itron-ca.com
>-------------------------------------
>
>

That is a real issue.

Yes, Clover technically fits into a 500 Hz slot - Pactor II's waveform is 
also shaped to fit in a 500 Hz slot. This pretty much follows a belief 
that narrow-band emissions conserve spectral space.

With the new high speed modems coming along, something inevitably will have 
to happen. I hope that this evolution happens in a way that will have the 
least amount of negative impact. I do suspect, however, that the notion 
will be fought every inch of the way. In short, yes, we probably can 
squeeze a number of orthogonal channels into 1 KHz and comply to the 
present regulations. It would be better than anything we have at the 
moment, but not a good long term solution.

It should be our mission to convince the digital community to support our 
efforts. I don't think that many know what we are intent on putting on the 
air, i.e., network vs keyboarding, modulation format and it's occupied 
bandwidth. The concepts must be formalized in clear language.

Without spending to much time phrasing this correctly - this is 
what I had thought about (of course without saying - open for debate, my 
own personal opinions):
 
        First, we have to show that we have superiour technology, i.e., 
        it gets traffic through, even under adverse conditions without 
        making dreaded demands on spectral usage. Instead of beating 300 
        baud packet to death, we need to illustrate an effective 
        alternate solution.

        Second, we have to convincingly show that narrow-band emissions are 
        as prone (probably more) to causing interference and suffering from 
        interference than does our proposed wide-band emissions. This holds 
        for man-made, or HF propagation wise. 

        For an interesting aside: the argument that the famous John Costas 
        had to defend when he was making attempts to convince 
        the IEEE of why wide-band emissions, was quite similar - 
        this was when spread-spectrum communications was born. I am certain
        that I don't have the vision and influence that Costas had, but it 
        is only a matter of time. You already know the outcome of that one. 
        
        To help the argument along, just for starters consider the 
        following: The impact on other nearby stations for a digital 
        modulated 100W packed into  500 Hz (0.2W/Hz) compared to 
        100W spead over 3KHz (0.033W/Hz). Even with the best filters,
        how wide will a high-powered signal really be? The main concern 
        that I have regarding wider bandwidth emissions is when an operator 
        indiscriminantly puts a big linear behind such a signal - this 
        would be disasterous and counterproductive.     
  
        The notion of low power/Hz, and ideally lots of Hz, is what it's 
        all about. The wider it gets, the better it gets (give and 
        take a bit of liberty). Our present parallel modems does not 
        use a speading function as in SS yet - at the very highest 
        rate it needs all the bandwidth, but at lower rate
        frequency diversity is used, in which case bandwidth is 
        used with redundancy.
        
        Another example: Would the principle ideas as used in the cellular 
        phone market have worked if it was based on narrow-band 
        transmission?         

        What is needed is an effective demonstration of what we are
        intending to use and win the support of the digital community. 


                              ---------------
        The real issue and crux of the matter is how to best utilize 
        our allocated spectrum by a number of simultaneous users without 
        QRM (leave poor operator judgement aside for the moment). Weigh 
        the advantage of replacing the current HF digital networks with an  
        efficient shared-channel mode.                
                              ---------------       


I expect that this issue will stir up a lot of discussion. This is an 
invitation to hear your views on how this should be approached.


73's

--Johan 
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Hi Johan -- has anyone checked the rules very recently.  In a thread
on netsig we had this posted.  

>> EVERYBODY is using AX.25 because the FCC says you MUST.
>
>The AX.25 requirement has been gone for about a year, and I didn't hear
>about it when it happened either.
>
>This is the new 97.109e:
>
>     (e) No station may be automatically controlled while transmitting
>     third-party communications, except a station participating as a
>     forwarding station in a message forwarding system.
>
>This paragraph used to contain the AX.25 requirement. It's gone.
>
>     Bruce Perens

While this does not direclty impact HF modes, it does impact networking and
BBS operations.

The main point is that the FCC, when aware of something needing to be done,
will change the rules when a section is open.  

So - we should think about talking to the
TAPR FCC Reg committee and some of the people at the league about this issue
so that they can be aware of it.  I would think that Paul Rinaldo is aware of it
-- the reason that many of the alternate protocols/modes were published
in the last Digital Communications Conferecne Proceedings was to be able to
have a reference to then include under some 'misc' section of the rules.
 
I forget all the manuvers required.    Phil is on the Future Systems
Committe and might be able to comment....??

>         First, we have to show that we have superiour technology, i.e., 
>         it gets traffic through, even under adverse conditions without 
>         making dreaded demands on spectral usage. Instead of beating 300 
>         baud packet to death, we need to illustrate an effective 
>         alternate solution.
> 
>         Second, we have to convincingly show that narrow-band emissions are 
>         as prone (probably more) to causing interference and suffering from 
>         interference than does our proposed wide-band emissions. This holds 
>         for man-made, or HF propagation wise. 
> 
> 
>                               ---------------
>         The real issue and crux of the matter is how to best utilize 
>         our allocated spectrum by a number of simultaneous users without 
>         QRM (leave poor operator judgement aside for the moment). Weigh 
>         the advantage of replacing the current HF digital networks with an  
>         efficient shared-channel mode.                
>                               ---------------       
> 
> 
> I expect that this issue will stir up a lot of discussion. This is an 
> invitation to hear your views on how this should be approached.
> 

This will indeed be an interesting debate in the future.  It already has
been.

Personally, I think we continue to improve the technology.  If we can make
HF communicatins work at better rates with better reliability I think we MUST
advance the state of the amateur art.

The problem is that you can spend lots of time worrying about others. While
all efforts should be made to communicate the technical advances -- for
every amateur willing to listen and understand there will be two more
sending flames.  However unfortunate -- a common amateur trait.   All of
amateur history is filled with examples: ssb/am, etc.

The golden rule of amateur radio -- "those that develop hardware or software
'rule'"  Pretty simple.  If you develop something that works better, faster,
and hopefully (for most hams) cheaper :-) then no matter how much yelling,
people will start to use it.  Will it impact others -- yes. Like any mode in
amateur radio.  

However, limitation of modes or speeds is not the correct manner in
which to enforce better operating correctness.

The problem is that it is easier to regulate then educate.   Amateurs might
be good at communications technology, but are in general terms poor
communicators.

Well, I'll get off my soap box.  

I hope the HF SIG keeps up the advancement of the amatuer art.  The rules
will eventually sort them self out.   We can work with the FCC to make sure
that what we are doing is seen as within the scope of the rules.

I must congratulate everyone on this SIG.  I feel that this is one of the
best SIGs we have in TAPR.  The level of discussion and technical research
is terrific to see happening!  Hats off to Johan and everyone else.

Cheers - Greg, WD5IVD
From FORRERJ@frl.orst.edu Thu Jul 20 12:19:21 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id MAB10999 for <hfsig@tapr.org>; Thu, 20 Jul 1995 12:19:10 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id KAA10207 for <hfsig@tapr.org>; Thu, 20 Jul 1995 10:19:11 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 20 Jul 95 10:24:11 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 20 Jul 95 10:24:08 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 20 Jul 1995 10:24:00 PST8PDT
Subject:       FFC part 97 on WWW?
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <5C8E62F48E5@frl.orst.edu>

Hi,

Does anyone know whether the FCC have a WEB page and whether
perhaps the latest reg's are available in electronic form?

Thanks in advance,

--Johan, KC7WW
From mcdermot@eagle.aud.alcatel.com Thu Jul 20 15:39:39 1995
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id PAA14668 for <hfsig@tapr.org>; Thu, 20 Jul 1995 15:39:34 -0500
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA29464; Thu, 20 Jul 95 15:39:31 CDT
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA01771; Thu, 20 Jul 95 15:39:30 CDT
Date: Thu, 20 Jul 95 15:39:30 CDT
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9507202039.AA01771@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:485] Re: Parallel vs Serial Tone

Eric Silbaugh brings up several good points in the debate on multi-carrier
vs. single carrier modulation (will this become the SSB vs. AM war of the
1990's ?)

> In the next section the authors present the results of some computer
> simulations showing that losses produced by frequency offsets and
> power backoff (due to the high peak amplitudes) in OFDM produce BERs
> much larger than those of an equalized simgle-tone system.
>

	It should be noted that high orders of modulation on single
carrier transmission (such as 64 QAM, etc.) also require a great
deal of linearity in the transmitter.  It can become debateable as
to which modulation format imposes the more severe linearity requirement!


> One observation the authors make is that frequency selective fading
> produces an irreducible BER in OFDM systems not using forward error
> correction (FEC).  Which leads to their last results showing that an
> OFDM system with FEC, coded OFDM (COFDM), can produce BERs identical
> to or slightly better than an equalized single-tone system (without
> FEC).  At the very least this shows the power, and necessity, of FEC!
>

	With HF, time-diversity is an easily achievable diversity (and
with HF, any kind of diversity helps greatly!).  Recent work on single
carrier modems has focused on equalization using minimization of the
Viterbi error metric, rather than minimization of the ISI, as a good
variable to reduce when adjusting the adaptive equalizer.  This of
course presumes convolutionally coded data.  Not sure which modulation
format requires the greater computational load for equalization.  Custom
silicon does this very well in HDSL and ADSL land-line systems, and the
equalizers are big.


> One unanswered question is the relative implemention complexity
> (DSP cycles) of COFDM versus single-tone modulation with frequency-
> domain equalization.  All the time domain equalizers I have seen are
> tremendous cycle hogs (not the Harley-Davidson kind either).  I
> wonder if frequency-domain equalization is any easier.  Can a DSP
> sound card handle it?
>
> It also seems that performance of the single-tone modem could be
> improved by adding FEC.  Of course, this would require even more DSP
> cycles, unless the host computer does the FEC decoding.
>
> COFDM would seem to have the initial advantage in reduced complexity
> (please correct me if this is wrong).  Past examples of working
> systems show that it can be done.  As long as the carrier tracking
> and high peak power limitations can be overcome it looks like this
> could produce a robust system.
>
> As others have noted a fairly inexpensive, robust, moderate speed
> HF modem will be a big step forward.  Basing it on DSP just means it
> can be improved without buying new hardware.  Keep up the good work!
>
>
> Eric, N2NNP
>
>     .:::.  .:::.  .:::.
>    :'     :'     :'              Eric E. Silbaugh
>   :::.   :::.    ':.           esilbaug@afit.af.mil
>  ::     ::         ':.
>  ::     ::           ::   All standard, non-standard, and
>   '::::::::::::::::::'       MIL-STD disclaimers apply
>


------------------------------------------------+-----------------------------
 Tom McDermott					| "All opinions expressed
 Alcatel Network Systems, Inc.			| are my own, and do not
 mcdermot@aud.alcatel.com			| represent those of Alcatel
   [ ICC'96 Technical Program Secretary ]	| Network Systems, Inc."
   [   June 23-27, 1996, Dallas, Tx.    ]	|
------------------------------------------------+-----------------------------
From k5yfw@sacdm10.kelly.af.mil Thu Jul 20 17:39:14 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id RAA17057 for <hfsig@tapr.org>; Thu, 20 Jul 1995 17:39:02 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0sZ4AL-0001zcC; Thu, 20 Jul 95 17:34 CDT
Message-Id: <m0sZ4AL-0001zcC@sacdm10.kelly.af.mil>
Date: Thu, 20 Jul 95 17:34:00 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:488] FFC part 97 on WWW?
To: hfsig@tapr.org
X-orig-date: Thu, 20 Jul 1995 12:39:26 -0500
X-orig-from: "Johan Forrer" <FORRERJ@frl.orst.edu>
X-orig-message-ID: <5C8E62F48E5@frl.orst.edu>

Johan,

In your message of 20 Jul 1995 at 1239 CDT, you write:
> Hi,
>
> Does anyone know whether the FCC have a WEB page and whether
> perhaps the latest reg's are available in electronic form?
>
> Thanks in advance,
>
> --Johan, KC7WW
>

For the FCC try:

http://fcc.goc:70/0h/AAA_HOMEPAGE.htlm  or http://www.fcc.gov

For Part 97 (the ARRL Official Copy)  Try:

http://www.acs.oakland.edu/barc/arrl/part97.html

        or ftp arrl.org and I think you can ftp down part 97.

I have visited www.acs.oakland.edu.

Walt
From chbrain@dircon.co.uk Tue Jul 25 14:54:29 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id OAA03010 for <hfsig@tapr.org>; Tue, 25 Jul 1995 14:54:21 -0500
Received: by felix.dircon.co.uk id AA26597
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Tue, 25 Jul 1995 20:54:05 +0100
Message-Id: <199507251954.AA26597@felix.dircon.co.uk>
Received: from ac034.pool.dircon.co.uk(193.128.230.34) by amnesiac via smap (V1.3)
	id sma026595; Tue Jul 25 20:53:51 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 25 Jul 1995 19:02:00 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Fed Std 1052

Hi,
 Does anyone know the current standing of Fed-Std 1052 Appendix B
I think (The data link protocol). I have a 1992 version of it I was just
wondering
if it has moved from proposed to an actual standard. I am also interested in
Fed-Std 1047, it was mentioned in QEX a few months back, I would like to read 
it, need something to help me sleep at night.
 There must be a way of finding out which standards are current.

Another thing anyone managed to get IIR filters to work on a TMS320C50 all
mine oscillate. I have been using PC-DSP to generate the coefficients and the
code in the TI C50 databook, all I get get is wonderful oscillation!

Regards Charles. 
-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From alanb@tsnake2.sr.hp.com Tue Jul 25 15:13:03 1995
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id PAA03263 for <hfsig@tapr.org>; Tue, 25 Jul 1995 15:11:27 -0500
Received: from hpmwtd.sr.hp.com by relay.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.3) id AA153112965; Tue, 25 Jul 1995 13:09:25 -0700
Received: from algae.sr.hp.com by hpmwtd.sr.hp.com with SMTP
	(15.11.1.6/15.5+ECS 3.3) id AA06738; Tue, 25 Jul 95 13:09:18 -0700
Received: by tsnake2.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA056022955; Tue, 25 Jul 1995 13:09:15 -0700
From: Alan Bloom <alanb@tsnake2.sr.hp.com>
Message-Id: <199507252009.AA056022955@tsnake2.sr.hp.com>
Subject: Bandwidth of digital modulation
To: hfsig@tapr.org
Date: Tue, 25 Jul 1995 13:09:14 -0800 (PDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Length: 4466      
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: quoted-printable

I ftp'd an up-to-date (April 26, 1995) copy of part 97 from oak.oakland.e=
du.
It's well hidden:  /pub/hamradio/arrl/infoserver/rib/part97.txt

The bottom line is that there are no explicit bandwidth limitations below=

28 MHz.  There is a maximum FSK shift of 1 kHz and a maximum symbol rate =

of 300 baud -- I suspect that the FCC expected that would impose a =

de facto bandwidth limitation based on 97.307(a), but they were =

probably not thinking about multi-carrier modulation!

AL N1AL

-------------------------------------------------------------------------=
-

Subpart D--Technical Standards
=2E...

S 97.305 Authorized emission types.
=2E...
     [Lists legal modulation modes for each frequency sub-band, =

     with footnotes referencing paragraphs in section 97.307(f)]

S 97.307 Emission standards.

   (a) No amateur station transmission shall occupy more bandwidth than =

necessary for the information rate and emission type being transmitted, i=
n =

accordance with good amateur practice.
=2E...
   (f) The following standards and limitations apply to transmissions on =

the frequencies specified in S 97.305(c) of this Part.

     [Phone bands below 29.0 MHz:]
     (1) No angle-modulated emission may have a modulation index greater =

than 1 at the highest modulation frequency.

     [Phone bands below 225 MHz:]
     (2) No non-phone emission shall exceed the bandwidth of a =

communications quality phone emission of the same modulation type. The =

total bandwidth of an independent sideband emission (having B as the firs=
t =

symbol), or a multiplexed image and phone emission, shall not exceed that=
 =

of a communications quality A3E emission.

    [CW bands below 28 MHz:]
    (3) Only a RTTY or data emission using a specified digital code liste=
d =

in  S 97.309(a) of this Part may be transmitted. The symbol rate must not=
 =

exceed 300 bauds, or for frequency-shift keying, the frequency shift =

between mark and space must not exceed 1 kHz.

    [28-28.3 MHz:]
    (4) Only a RTTY or data emission using a specified digital code liste=
d =

in  S 97.309(a) of this Part may be transmitted. The symbol rate must not=
 =

exceed 1200 bauds. For frequency-shift keying, the frequency shift betwee=
n =

mark and space must not exceed 1 kHz.

    [50.1-54 MHz, 144.1-148 MHz:]
    (5) A RTTY, data or multiplexed emission using a specified digital =

code listed in  S 97.309(a) of this Part may be transmitted. The symbol =

rate must not exceed 19.6 kilobauds.  A RTTY, data or multiplexed emissio=
n =

using an unspecified digital code under the limitations listed in S =

97.309(b) of this Part also may be transmitted. The authorized bandwidth =
is =

20 kHz.

     [222-225 MHz, 420-450 MHz:]
     (6) A RTTY, data or multiplexed emission using a specified digital =

code listed in S 97.309(a) of this Part may be transmitted. The symbol ra=
te =

must not exceed 56 kilobauds. A RTTY, data or multiplexed emission using =
an =

unspecified digital code under the limitations listed in S 97.309(b) of =

this Part also may be transmitted. The authorized bandwidth is 100 kHz.

     [Amateur bands above 902 MHz:]
     (7) A RTTY, data or multiplexed emission using a specified digital =

code listed in S 97.309(a) of this Part or an unspecified digital code =

under the limitations listed in  S 97.309(b) of this Part may be =

transmitted.

     [51-54 MHz, 144.1-148 MHz, >222 MHz:]
     (8) A RTTY or data emission having designators with A, B, C, D, E, F=
, =

G, H, J or R as the first symbol; 1, 2, 7 or 9 as the second symbol; and =
D =

or W as the third symbol is also authorized.
=2E...
     [Paragraphs 9, 10, and 11 deal with novice CW privileges and
     phone operation in regions 1 and 3.]

     [>902 MHz:]
     (12) Emission F8E may be transmitted.

     [219-220 MHz:] =

     (13) A data emission using an unspecified digital code under the =

limitations listed in =A7 97.309(b) of this Part also may be transmitted.=
  =

The authorized bandwidth is 100 kHz. =


S 97.309 RTTY and data emission codes.

   (a) [Specifies legal codes:  5-unit Baudot, 7-unit AMTOR, 7-unit ASCII=
]

   (b) Where authorized by S S 97.305(c) and 97.307(f) of this Part, a =

station may transmit a RTTY or data emission using an unspecified digital=
 =

code, except to a station in a country with which the United States does =

not have an agreement permitting the code to be used. RTTY and data =

emissions using unspecified digital codes must not be transmitted for the=
 =

purpose of obscuring the meaning of any communication. ...

[end]

From FORRERJ@frl.orst.edu Tue Jul 25 15:44:05 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id PAA03641 for <hfsig@tapr.org>; Tue, 25 Jul 1995 15:43:58 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id NAA04015 for <hfsig@tapr.org>; Tue, 25 Jul 1995 13:43:40 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 25 Jul 95 13:48:53 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 25 Jul 95 13:48:31 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 25 Jul 1995 13:48:24 PST8PDT
Subject:       Re: [HFSIG:491] Fed Std 1052
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <64451CC67C0@frl.orst.edu>

Hi Charles,

Re: IIR filters. If you have a pole(s) close to the unity circle that may 
happen. Also if you are aiming for very high Q's, i.e., narrow passbands 
with brickwall filters, this may lead to that situation. For IIR 
filter architectures, part of the filter's output is determined 
both by past input as well as past output. It is not difficult to see that 
it doesn't take much to get the output history overpower the output 
history. Typically, once oscillation starts, you may even take the input to 
zero and it will merrily feed back output history and maintain the 
oscillatory state. The dampening factor is supposed to take care of 
this. 

Just a thought: do you clear the input and output history on 
initialization, or do you just leave use the garbage that is in memory? 
Does it start up OK and starts oscillation only when it sees a large signal?
In the W9GR software, you can quite easily get the IIR input filter to 
saturate by driving the audio input to hard, however, there is sufficient 
dampening to recover - one can see it return to normal, however like 
slow release AGC. 

Numerical roundoff error is another issue that may add to your problem: 
since you only have a limited wordsize to work with, it is inevitable that 
you will encounter roundoff errors for each result that is computed. 
Right? The bad news is that each roundoff error are fed back and used as 
part of the input to the filter on the next round, so you have these 
errors in a recursive positive feedback loop! Certainly not an additive 
noise source like for instance FIR filters. 

There are several IIR filter designs around. Those that use an analog 
counterpart, does pre-warping, and then the transformation. This is a 
common way of doing them and I suspect that is what you may be using. There 
are some other exotic means of designing IIR filters, though I have never 
attempted that.

I don't know whether this helped. Good luck anyway.

--Johan, KC7WW

From chbrain@dircon.co.uk Wed Jul 26 00:40:02 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id AAA11838 for <hfsig@tapr.org>; Wed, 26 Jul 1995 00:39:58 -0500
Received: by felix.dircon.co.uk id AA13589
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Wed, 26 Jul 1995 06:39:47 +0100
Message-Id: <199507260539.AA13589@felix.dircon.co.uk>
Received: from ac037.pool.dircon.co.uk(193.128.230.37) by amnesiac via smap (V1.3)
	id sma013587; Wed Jul 26 06:39:34 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 26 Jul 1995 04:47:35 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re:IIR filters an 8ary FSK modem

>Hi Charles,

>I don't know whether this helped. Good luck anyway.
>
>--Johan, KC7WW
>
>
Hello,
Well after I twigged that the coefficients are different in the TI
description to the
PC-DSP program i,e  a coeffs are really the B ones etc, things started to 
work better. At start up there is no oscillation and whne a signal is in the 
filters passband there is no problem, however outside the passband the output
appears almost totally random and is larger than the wanted signal when tuned
to the passband.
 I am still looking at the 8 ary modem, it seems to work with a 32 point FFT
fed with real values. Using FIR filters pushes the available processing, so I
thought I would use IIR as that is what I started with and got nowhere!
 It would be nice to get something that would work on the DSP93, the FFT
approach is fine on a C50 but I have my doubts about the C25 as I don't think 
there would be enough cycles.
 I know Fredricks managed to get it working with just a C12 so it is possible.

I was woundering what CAD programs people are using, as I menitioned I am
using PC-DSP and I have heard MATLAB being mentioned, just curious.

Regards Charles  
-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From mcdermot@eagle.aud.alcatel.com Thu Jul 27 08:06:05 1995
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id IAA29164 for <hfsig@tapr.org>; Thu, 27 Jul 1995 08:05:55 -0500
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1)
	id AA12254; Thu, 27 Jul 95 08:05:50 CDT
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA01613; Thu, 27 Jul 95 08:05:49 CDT
Date: Thu, 27 Jul 95 08:05:49 CDT
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9507271305.AA01613@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:494] Re:IIR filters an 8ary FSK modem


> Hello,
> Well after I twigged that the coefficients are different in the TI
> description to the
> PC-DSP program i,e  a coeffs are really the B ones etc, things started to
> work better. At start up there is no oscillation and whne a signal is in the
> filters passband there is no problem, however outside the passband the
output
> appears almost totally random and is larger than the wanted signal when
tuned
> to the passband.
>  I am still looking at the 8 ary modem, it seems to work with a 32 point FFT
> fed with real values. Using FIR filters pushes the available processing, so
I
> thought I would use IIR as that is what I started with and got nowhere!
>  It would be nice to get something that would work on the DSP93, the FFT
> approach is fine on a C50 but I have my doubts about the C25 as I don't
think
> there would be enough cycles.
>  I know Fredricks managed to get it working with just a C12 so it is
possible.
>
> I was woundering what CAD programs people are using, as I menitioned I am
> using PC-DSP and I have heard MATLAB being mentioned, just curious.
>
> Regards Charles


	Charles: a couple of points you might look for:

	IIR filters, as Johan mentions, are sensitive to numerical errors
due to the feedback.  You should make sure that you are rounding, not
truncating during your calculations (there's some flags in the TMS320
to control this).  Secondly, all intermediate calculations should be
done with 32-bit arithmetic, not 16 bit arithmetic, and the intermediate
results must be stored as 32-bit numbers.  Additionally, you should
set the TMS320 flags so that the accumulator clamps at the rail, rather
than rolling-over.

	And, as Johan has mentioned, if there are any poles close to the
unit-Z circle, then the required processing accuracy can even exceed 32
bits.

	You should be very careful in your quantization of the coefficients.
I would recommend using 32-bit coefficients in many cases.  It may not
be acceptable to take whatever you get from your CAD program and
truncate the coefficients to 16 bits.  You CAD program may or may not
calculate the coefficients with adequate precision for the application.

	FIR filters, of course do not in general require such high
precision, but IIR filters do take work to 'tame'.  Good luck.


							- Tom, N5EG

------------------------------------------------+-----------------------------
 Tom McDermott					| "All opinions expressed
 Alcatel Network Systems, Inc.			| are my own, and do not
 mcdermot@aud.alcatel.com			| represent those of Alcatel
   [ ICC'96 Technical Program Secretary ]	| Network Systems, Inc."
   [   June 23-27, 1996, Dallas, Tx.    ]	|
------------------------------------------------+-----------------------------
From FORRERJ@frl.orst.edu Thu Jul 27 10:59:12 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id KAA31060 for <hfsig@tapr.org>; Thu, 27 Jul 1995 10:58:56 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA00325 for <hfsig@tapr.org>; Thu, 27 Jul 1995 08:58:54 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Thu, 27 Jul 95 9:03:41 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 27 Jul 95 8:55:42 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Thu, 27 Jul 1995 08:55:41 PST8PDT
Subject:       Re: [HFSIG:492] Bandwidth of digital modulation
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <66F71A05C4B@frl.orst.edu>

Hi Al,

----some lines deleted----


>I ftp'd an up-to-date (April 26, 1995) copy of part 97 from 
oak.oakland.edu.
>It's well hidden:  /pub/hamradio/arrl/infoserver/rib/part97.txt
>
>The bottom line is that there are no explicit bandwidth limitations below
>28 MHz.  There is a maximum FSK shift of 1 kHz and a maximum symbol rate 
>of 300 baud -- I suspect that the FCC expected that would impose a 
>de facto bandwidth limitation based on 97.307(a), but they were 
>probably not thinking about multi-carrier modulation!
>
>
>AL N1AL
>

----further lines deleted---

You make a good point. To elaborate a little further on this 
issue, here is how HAL justifies Clover II. I quote literally from an 
article from Communications Qaurterly by Bill Henry, K9GWT, and Ray Petit, 
W7GHM.

    "For those who may be wondering how
    this complex modulation fits Part 97 of the
    FCC Rules and Regulations, let us assure
    you that all CLOVER modes are indeed in
    conformance with existing rules. CLOVER
    passes only one data stream and is therefore
    not a "multiplex" modulation format. The
    CLOVER modulation output is audio tones
    that are used to drive the output to an SSB
    transmitter. This is CCIR mode "J2,"
    which is allowed. The CLOVER base data
    rate is 31.25 bits-per-second -- well within
    the 300 baud maximum HF limitation. The
    CCIR emisssion designation for CLOVER-II
    is "500HJ2DEN".

OK - this obviously deals with a number of issues that we also have been
discussing. Comments?

I wish to prepare a few things for the upcoming Digital Conference -
one is to initiate the motion for updating the rules on digital
communications. I sense that there is willingness to accept the fact that 
technolgy has advanced. Please think a bit about what the real issues as far 
as rulemaking are concerned to reflect best the needs for modern digital 
HF communications. I will bring that up with the appropiate person(s). Keep 
in mind that we are living in a world community, so I also would like to 
hear what the regulations allow in other countries in this regard.


Regards,

--Johan, KC7WW

From sid@doe.ernet.in Thu Jul 27 23:24:21 1995
Received: from sangam.ncst.ernet.in (sangam.ncst.ernet.in [144.16.11.1]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id XAA08497 for <hfsig@tapr.org>; Thu, 27 Jul 1995 23:24:05 -0500
Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.12/8.6.6) with UUCP id JAA28930 for hfsig@tapr.org; Fri, 28 Jul 1995 09:54:53 +0530
Received: from mahavir.doe.ernet.in by doe.ernet.in (4.1/SMI-4.1-MHS-7.0)
	id AA14974; Fri, 28 Jul 95 09:49:22+050
Received: by mahavir.doe.ernet.in (4.1/SMI-4.1-MHS-7.0)
	id AA04127; Fri, 28 Jul 95 09:50:18+0530
Date: Fri, 28 Jul 1995 09:50:17 +0530 (GMT+05:30)
From: Siddhartha Bhattacharjee <sid@doe.ernet.in>
Subject: Help !!!
To: hfsig@tapr.org
In-Reply-To: <9507271305.AA01613@eagle.aud.alcatel.com>
Message-Id: <Pine.3.89.9507280937.B3640-0100000@mahavir>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Dear friends,

I have got badly stuck up for want of a silly information and
hence decided to trouble the HFSIG guys for a possible help.

I need the chip details of XR2206 chip with specific application
to the AFSK generation for 200/170 Hz and 1KHz shift for use
in HF and VHF use. I tried all possible sources in Delhi and
with my friends and colleagues. It appears that the EXAR chips are 
not very popular here and hence no manual or application note can
be found here. I would appreciate an electronic copy of the 
schematics or the data sheet etc., first uuencoded and then
mailed to sid@doe.ernet.in.

Thanks to everybody in anticipation.

73s all round,

Sid.
From karn@unix.ka9q.ampr.org Fri Jul 28 02:15:32 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.90.35]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id CAA11507 for <hfsig@tapr.org>; Fri, 28 Jul 1995 02:15:28 -0500
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id AAA26888; Fri, 28 Jul 1995 00:09:48 -0700
Date: Fri, 28 Jul 1995 00:09:48 -0700
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199507280709.AAA26888@unix.ka9q.ampr.org>
To: forrerj@ucs.orst.edu
CC: hfsig@tapr.org
In-reply-to: <9507140601.AA12819@ucs.orst.edu> (forrerj@ucs.orst.edu)
Subject: Re: [HFSIG:465] Re: ANDVT TACTERM Documentation

>instances. If a "dead" zone or guard interval is used (i.e. the
>integrator/FFT excuding that part of the signal), he shows a significant
>improvement in demodulator S/N is possible due to using the guard band. 

Seems to me that applying a window function to the FFT in the
demod should accomplish this very nicely.

By the way, I see that the bogus "Reply-To: hfsig@tapr.org" header is
still present, requiring me to manually edit headers when I reply to
send a copy to the person in the From: line...

Phil
From karn@qualcomm.com Fri Jul 28 02:29:15 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.90.35]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id CAA11609 for <hfsig@tapr.org>; Fri, 28 Jul 1995 02:29:10 -0500
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id AAA26950; Fri, 28 Jul 1995 00:29:07 -0700
Date: Fri, 28 Jul 1995 00:29:07 -0700
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199507280729.AAA26950@unix.ka9q.ampr.org>
To: forrerj@ucs.orst.edu
CC: hfsig@tapr.org
Reply-To: karn@qualcomm.com
In-reply-to: <9507141724.AA15857@ucs.orst.edu> (forrerj@ucs.orst.edu)
Subject: Re: [HFSIG:471] Re: ANDVT TACTERM Documentation

>If the sync pre-amble is designed cleverly, it may be possible to write an
>algorithm that is hunting for it all the time - a daemon. When it sees it,
>it forces a frame reset. As an interesting aside, in Pactor, the designers

HDLC flags work exactly like this -- get a flag, go back to the known
starting state (and finish whatever packet you were working
on). Unfortunately, HDLC flags are much too small to be very robust over
radio. A PN sequence seems more reasonable.

Phil

From Danny@edstks1.demon.co.uk Fri Jul 28 09:57:50 1995
Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id JAA14259 for <hfsig@tapr.org>; Fri, 28 Jul 1995 09:57:23 -0500
Received: from post.demon.co.uk by disperse.demon.co.uk id aa17648;
          28 Jul 95 14:49 +0100
Received: from edstks1.demon.co.uk by post.demon.co.uk id aa05467;
          28 Jul 95 14:49 +0100
Date: Fri, 28 Jul 1995 08:56:54 GMT
From: Danny Higgins <Danny@edstks1.demon.co.uk>
Reply-To: Danny@edstks1.demon.co.uk
Message-Id: <219@edstks1.demon.co.uk>
To: hfsig@tapr.org
Subject: Re: [HFSIG:496] Re: Bandwidth of digital modulation
X-Mailer: PCElm 1.10
Lines: 68

In message <66F71A05C4B@frl.orst.edu> hfsig@tapr.org writes:
> Hi Al,
> 
> ----some lines deleted----
> 
> 
> >I ftp'd an up-to-date (April 26, 1995) copy of part 97 from 
> oak.oakland.edu.
> >It's well hidden:  /pub/hamradio/arrl/infoserver/rib/part97.txt
> >
> >The bottom line is that there are no explicit bandwidth limitations below
> >28 MHz.  There is a maximum FSK shift of 1 kHz and a maximum symbol rate 
> >of 300 baud -- I suspect that the FCC expected that would impose a 
> >de facto bandwidth limitation based on 97.307(a), but they were 
> >probably not thinking about multi-carrier modulation!
> >
> >
> >AL N1AL
> >
> 
> ----further lines deleted---
> 
> You make a good point. To elaborate a little further on this 
> issue, here is how HAL justifies Clover II. I quote literally from an 
> article from Communications Qaurterly by Bill Henry, K9GWT, and Ray Petit, 
> W7GHM.
> 
>     "For those who may be wondering how
>     this complex modulation fits Part 97 of the
>     FCC Rules and Regulations, let us assure
>     you that all CLOVER modes are indeed in
>     conformance with existing rules. CLOVER
>     passes only one data stream and is therefore
>     not a "multiplex" modulation format. The
>     CLOVER modulation output is audio tones
>     that are used to drive the output to an SSB
>     transmitter. This is CCIR mode "J2,"
>     which is allowed. The CLOVER base data
>     rate is 31.25 bits-per-second -- well within
>     the 300 baud maximum HF limitation. The
>     CCIR emisssion designation for CLOVER-II
>     is "500HJ2DEN".
> 
> OK - this obviously deals with a number of issues that we also have been
> discussing. Comments?
> 
> I wish to prepare a few things for the upcoming Digital Conference -
> one is to initiate the motion for updating the rules on digital
> communications. I sense that there is willingness to accept the fact that 
> technolgy has advanced. Please think a bit about what the real issues as far 
> as rulemaking are concerned to reflect best the needs for modern digital 
> HF communications. I will bring that up with the appropiate person(s). Keep 
> in mind that we are living in a world community, so I also would like to 
> hear what the regulations allow in other countries in this regard.
> 
> 
> Regards,
> 
> --Johan, KC7WW
> 
> 
Hi, Johan. You seem to have sent this to me by mistake.

I have found the HFSIG and have about 1 MByte of back discussion to catch up
with. How do I join in the discussion?

-- 
Danny Higgins G3XVR
From bm@lynx.ve3jf.ampr.org Fri Jul 28 12:05:19 1995
Received: from lynx.ve3jf.ampr.org (lynx.ve3jf.ampr.org [44.135.96.100]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id MAA15504 for <hfsig@tapr.org>; Fri, 28 Jul 1995 12:05:11 -0500
Received: by lynx.ve3jf.ampr.org (Linux Smail3.1.28.1 #14)
	id m0sbspu-0002ruC; Fri, 28 Jul 95 17:04 GMT
Message-Id: <m0sbspu-0002ruC@lynx.ve3jf.ampr.org>
From: bm@lynx.ve3jf.ampr.org (Barry McLarnon VE3JF)
Subject: Re: [HFSIG:498] Re: ANDVT TACTERM Documentation
To: hfsig@tapr.org
Date: Fri, 28 Jul 1995 17:04:34 +0000 (GMT)
In-Reply-To: <199507280709.AAA26888@unix.ka9q.ampr.org> from "Phil Karn" at Jul 28, 95 02:27:59 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 889       

> By the way, I see that the bogus "Reply-To: hfsig@tapr.org" header is
> still present, requiring me to manually edit headers when I reply to
> send a copy to the person in the From: line...

It's not bogus, it's intentional.  The mailing lists that I administer
are set up the same way, so that the default is for replies to be seen
by all, and all can learn from them.  The underlying assumption is that
the list is intended for open discussions, and that the majority of
replies contain information which is of interest to many on the list.
The downside is the risk of embarrassment when replies which were
intended to be personal get sent to the list.  Still, I think it's a
reasonable tradeoff on a high-SNR list such as this one.

> Phil

Barry

-- 
Barry McLarnon  VE3JF/VA3TCP 
Ottawa Amateur Radio Club Packet Working Group
Email: bm@hydra.carleton.ca  or bm@lynx.ve3jf.ampr.org
From karn@qualcomm.com Sat Jul 29 17:28:50 1995
Received: from qualcomm.com (qualcomm.com [129.46.50.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id RAA25520 for <hfsig@tapr.org>; Sat, 29 Jul 1995 17:28:47 -0500
Received: from unix.ka9q.ampr.org (root@unix.ka9q.ampr.org [129.46.90.35]) by qualcomm.com (8.6.12/QC-MAIN-2.1) with ESMTP id WAA01570 for <hfsig%tapr.org@qualcomm.com>; Fri, 28 Jul 1995 22:03:13 -0700
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id NAA28905; Fri, 28 Jul 1995 13:49:09 -0700
Date: Fri, 28 Jul 1995 13:49:09 -0700
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199507282049.NAA28905@unix.ka9q.ampr.org>
To: hfsig@tapr.org
In-reply-to: <5B3E2247CF4@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:486] FCC Regulations for HF digital
Reply-To: karn@qualcomm.com

>        To help the argument along, just for starters consider the 
>        following: The impact on other nearby stations for a digital 
>        modulated 100W packed into  500 Hz (0.2W/Hz) compared to 
>        100W spead over 3KHz (0.033W/Hz). Even with the best filters,
>        how wide will a high-powered signal really be? The main concern 

It may not be 100W spread over 3KHz, it might be much less. One of the
advantages of going wider is the ability to use LESS total power. So
you can often reduce W/Hz twice, once by going wider and again by
using less total power.

>        Another example: Would the principle ideas as used in the cellular 
>        phone market have worked if it was based on narrow-band 
>        transmission?         

No. There are good reasons, aside from simplicity, why AMPS chose FM
over SSB. There are even better reasons for going wider, as with CDMA.


Phil
From karn@qualcomm.com Sat Jul 29 17:30:11 1995
Received: from qualcomm.com (qualcomm.com [129.46.50.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id RAA25566 for <hfsig@tapr.org>; Sat, 29 Jul 1995 17:30:06 -0500
Received: from unix.ka9q.ampr.org (root@unix.ka9q.ampr.org [129.46.90.35]) by qualcomm.com (8.6.12/QC-MAIN-2.1) with ESMTP id WAA01565 for <hfsig%tapr.org@qualcomm.com>; Fri, 28 Jul 1995 22:03:09 -0700
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id NAA28909; Fri, 28 Jul 1995 13:56:01 -0700
Date: Fri, 28 Jul 1995 13:56:01 -0700
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199507282056.NAA28909@unix.ka9q.ampr.org>
To: hfsig@tapr.org
Reply-To: karn@qualcomm.com
In-reply-to: <199507200221.VAA10073@dingus.n5lyt.datarace.com> (message from Greg Jones on Wed, 19 Jul 1995 21:47:13 -0500)
Subject: Re: [HFSIG:487] Re: FCC Regulations for HF digital

>So - we should think about talking to the
>TAPR FCC Reg committee and some of the people at the league about this issue
>so that they can be aware of it.  I would think that Paul Rinaldo is aware of it
>>n-- the reason that many of the alternate protocols/modes were published
>in the last Digital Communications Conferecne Proceedings was to be able to
>have a reference to then include under some 'misc' section of the rules.
 
>I forget all the manuvers required.    Phil is on the Future Systems
>Committe and might be able to comment....??

Most of the members of the Future Systems committee are already sold
on this stuff. So is the FCC, for that matter -- they've shown a remarkable
openness to rule changes that promote technical progress.

The problem, in my opinion, lies with the average ham and with the
ARRL leadership who represents them. This has been very apparent in
the recent attempts to liberalize the SS rules. They don't understand
the technology and its benefits, and as often happens people fear what
they don't understand.

The key here is education, backed up by convincing demonstrations of
the new technology in action. STAs can be easily had if they're necessary.

Phil

From k5yfw@sacdm10.kelly.af.mil Sat Jul 29 23:34:45 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id XAA29139 for <hfsig@tapr.org>; Sat, 29 Jul 1995 23:34:39 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0scPdH-0002AeC; Sat, 29 Jul 95 23:05 CDT
Message-Id: <m0scPdH-0002AeC@sacdm10.kelly.af.mil>
Date: Sat, 29 Jul 95 23:05:42 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:503] Re: FCC Regulations for HF digital
To: hfsig@tapr.org
X-orig-date: Sat, 29 Jul 1995 17:34:33 -0500
X-orig-from: Phil Karn <karn@unix.ka9q.ampr.org>
X-orig-message-ID: <199507282056.NAA28909@unix.ka9q.ampr.org>



In Phil's message of 29 Jul 1995 at 1734 CDT, he writes:
> >So - we should think about talking to the
> >TAPR FCC Reg committee and some of the people at the league about this issue
> >so that they can be aware of it.  I would think that Paul Rinaldo is aware of it
> >>n-- the reason that many of the alternate protocols/modes were published
> >in the last Digital Communications Conferecne Proceedings was to be able to
> >have a reference to then include under some 'misc' section of the rules.
>
> >I forget all the manuvers required.    Phil is on the Future Systems
> >Committe and might be able to comment....??
>
> Most of the members of the Future Systems committee are already sold
> on this stuff. So is the FCC, for that matter -- they've shown a remarkable
> openness to rule changes that promote technical progress.
>
> The problem, in my opinion, lies with the average ham and with the
> ARRL leadership who represents them. This has been very apparent in
> the recent attempts to liberalize the SS rules. They don't understand
> the technology and its benefits, and as often happens people fear what
> they don't understand.
>
> The key here is education, backed up by convincing demonstrations of
> the new technology in action. STAs can be easily had if they're necessary.

******* IMHO, the "convencing demonstration" is the key to acceptance. *******


73,  Walt

PS, sorry of the additional bandwith of the above but felt it had to
be read before reading my comments.  -- k5yfw
From Sivula@ncsmsg01es.ntc.nokia.com Mon Jul 31 02:21:45 1995
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id CAA08794 for <hfsig@tapr.org>; Mon, 31 Jul 1995 02:21:37 -0500
Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi [131.228.138.80]) by axl01it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id KAA10460 for <hfsig@tapr.org>; Mon, 31 Jul 1995 10:20:22 +0300
Received: by ntcite01es.ntc.nokia.com with Microsoft Mail
	id <301C92BA@ntcite01es.ntc.nokia.com>; Mon, 31 Jul 95 10:22:18 eet
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com>
To: "'HFSIG'" <hfsig@tapr.org>
Subject: DWAIT/DTIME/T2 KISS parameter number
Date: Mon, 31 Jul 95 10:13:00 eet
Message-ID: <301C92BA@ntcite01es.ntc.nokia.com>
Encoding: 62 TEXT
X-Mailer: Microsoft Mail V3.0


Hello everyone,

in testing Pawels multitone modem we came across a problem with the DSP4 OS, 
Leonid. It does
not support the DTIME/DWAIT/T2 parameter. Jarkko promised to code it into 
Leonid but we do not
have any documents on this feature. The jamming sequence of the modem makes 
the rx fall out of
synnc which results in immediate ack. if we use maxframe > 1 the ack is 
transmitted on the following
I frame, creating collision.

The parameter that we need is the one that adds a wait-time before *every* 
transmission. Now
Leonid works so, that if there is no carrier on the frequency when it wants 
to transmit, it transmits
immediately. Only if there is a carrier on at the moment of attempted 
transmission it starts the
persistence / slottime lottery. Today most TNCs have a parameter which 
defines how long to
wait everytime before transmission. This is called DWAIT/DTIME or T2. 
Correct me if I am wrong.

What is the KISS parameter number for this parameter? It is needed in order 
to make Leonid
compatible with existing KISS drivers like TFKISS and TFPCR. If anyone of 
you have an updated
list of the KISS parameters it would be more than appreciated.

We have managed to make quite good QSO's with the 9 carrier multitone modem. 
The original 15
carrier version did not work well, but the 9 carrier version works ok. We 
could not make any reasonable
file transfer tests because of this KISS parameter lacking. We had a long 
ragchew using the modem
and could verify that it except this KISS problem it worked quite ok. No 
results are available on the
bps speed yet. When we can transmit multiple packets we will run several 
file transfer tests in order
to calculate real transmission speed. We also plan to make more tests on 
longer distances from Jonis
summer cottage and using the crowded lowbands, when we get a fully operating 
modem.

The 9QPSK modem is according to our tests a fairly good working model. It is 
sensitive to distortion, but
works fairly well with low modulation levels. There is a annoying brum on 
the TX line when not transmitting
which originates from the PSK software, not the electronics. This could be 
checked out by someone who
knows the software. It is annoying when we use the same rigs for talkback, 
as the hum is coming trough to the mic side and to the SSB audio.

We will be back with more tests and results after the Leonid modification.

The test equiupments we use are in the both ends DSP4 and FT757GX TRX with 
vertical antennas. Power has been about 30 W. We have been working on 29.100 
MHz SSB and FM. The distance between me and
Joni, OH2NJR is about 10 km.

73, Timo OH6KK/OH2LVZ
From FORRERJ@frl.orst.edu Mon Jul 31 10:41:05 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id KAA12846 for <hfsig@tapr.org>; Mon, 31 Jul 1995 10:41:01 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA15670 for <hfsig@tapr.org>; Mon, 31 Jul 1995 08:40:50 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 31 Jul 95 8:45:47 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 31 Jul 95 8:45:38 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 31 Jul 1995 08:45:29 PST8PDT
Subject:       Re: [HFSIG:505] DWAIT/DTIME/T2 KISS parameter number
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <6CF49693604@frl.orst.edu>

Dear Timo,

Outstanding! Keep us informed on how things progress. 

I am busy looking into improving the transmitted pulse shaping. This 
probably will clean up spectral leakage and at the same time help a bit on 
tuning the signal. Some form of tuning indication would help things too.

Keep up the good work - I am sure Pawel will be delighted to hear the 
news when he returns after vaction. 

Good work with the 9-tone version, Frode. Do you think that it is the 
SSB filters causing the problem with the 15-tone version?

73's

--Johan, KC7WW
